Hi there,
we’re experiencing trouble with G400-D modules (tested on about 15 of them). The RTC inside keeps loosing time - in 24 hours it is ~30 minutes late. There was no such problem with ChipworkX…
Is there any workaround you’d recommend?
Thanks
Sebastian
Same here. Looks to me that the crystal / capacitors responsible for the clock are out of tolerance or have a wrong value.
We will look into it and report back, thanks
Characterize the time loss and periodically update the RTC via software.
Just watched the schematic of the fez-raptor but there’s no external crystal used for 32Khz RTC oscillator. So it must be the internal 32Khz oscillator that’s been used for RTC. Unfortunately this oscillator is specified in the atmel data sheet to run between 20 kHz and 44 kHz. Not really useful for an ‘real time clock’ a cheap and accurate solution is to use one of the RTC boards based on the DS3231 ic… for example http://www.dx.com/p/ds3231-high-precision-real-time-clock-module-blue-3-3-5-5v-222910#.U2zqBcYmWDc
Hi:
I have been conducting time tests on two FEZRaptor boards and, as an example, 1 board syncronized time with NIST last night at 22:38 hours. This morning the NETMF time (using DateTime) lagged NIST by 1029 seconds while the RTC (using RealTimeClock.now) led NIST time by 3 seconds. A code fragment is below. The results you report are consistent with the NETMF time, not the RTC time, so that might be the problem.
These results are using the latest 4.3 beta, but mirror what I have seen with 4.2.
Private Sub PostTimeThread()
Dim i As Integer = 0
Dim TimeRecorder As New WriteToSDcard("PostTimeThread.csv")
TimeRecorder.Record("NETMF Time,RTC Time@ check, NETMFTime@ Check,NIST time, NIST server,DeltaNIST-NETMF Time, DeltaNIST-RTC", True, False)
Do While TimeRecorder.Ready
' If useBarometer Then barometer.RequestMeasurement()
If i Mod 240 = 0 Then
Dim it As New SetNISTTime ' make the time read class
Dim timeserver As String = "" ' name of time server
Dim receiveRTCtime As DateTime ' time read by RTC clock when NIST data reveived
Dim receiveNetMFTime As DateTime ' time read by NETMF when NIST data received
Dim NIST_Time As DateTime = GetNISTTime.NTPTimeInArray(TimeZoneOffset, timeserver, receiveNetMFTime, receiveRTCtime) ' now set the clock with time server call
Dim deltaNETMFTime As Double = (NIST_Time.Ticks - receiveNetMFTime.Ticks) / TimeSpan.TicksPerSecond
Dim rtcTime As DateTime = RealTimeClock.Now
Dim deltaRTCtime As Double = (NIST_Time.Ticks - receiveRTCtime.Ticks) / TimeSpan.TicksPerSecond ' delta times are in seconds
TimeRecorder.Record(receiveRTCtime.ToString & "," & receiveNetMFTime.ToString & "," & NIST_Time.ToString & "," & timeserver & "," & deltaNETMFTime.ToString("F2") & "," & deltaRTCtime.ToString("F2"), True, True)
End If
characterDisplay2.SetCursorPosition(1, 0)
characterDisplay2.Print(RealTimeClock.Now.ToString)
Thread.Sleep(1000)
Mainboard.SetDebugLED(i Mod 2 = 0)
i += 1
Loop
Stop
End Sub
Update: we are, and have been, actively working on this issue!!
Based on a lot of experimentation (mostly John) and reading (John & I)… I’ve come to the following conclusion (folks in the community that know more than I – please correct any errors you spot).
The absolute best we’re going to get out of the RTC with our current crystal is around +/- 2 sec.s per day. This will vary greatly based on temperature away from 25 degrees Celsius. It will probably be skewed.
Your variance may also be affected by the environment of the G400 (power supply, surrounding electrical/magnetic fields, and acceleration).
From my reading, this is not a bad value. So, for long term accuracy, your design will require a means of synchronizing the RTC. NOTE: this is for GHI RTC API; not the traditional NETMF API.
We are still working on the issue, but here is what we have so far:
There are two issues actually: time keeping in DateTime.Now and our RealTimeClock.GetDateTime are both off. As it stands now, RTC is powered by the external crystal and DateTime is powered by the internal crystal until RTC is turned on at which point is also powered by the external crystal.
As RobvanSchelven pointed out, the internal crystal has a wide range of variance. We have confirmed this in testing, many different G400’s lose varying amounts of time, sometimes drastically. The solution to that problem is to power DateTime from the external crystal at all times. Until that change is made, enabling RTC will set DateTime to use the external crystal.
Once both clocks are on the external crystal, and testing over 10 G400s, DateTime gains a constant 7 seconds every 5 minutes (which we are still working on fixing) and RTC changes are almost negligible: a loss of around 4 seconds per day.
To work around the 7 second gain for DateTime, you can periodically update it by calling Microsoft.SPOT.Hardware.Utility.SetLocalTime with either the RTC or some network time. To work around the RTC loss, you can either add ~4.89 seconds once per day or sync it with network time.
Hi John,
4 seconds a day are still quite bad, but much better than half an hour 
Can I ask you, please, for a simple code example how to set up the RTC?
Would just GHI.Premium.Hardware.RealTimeClock RTC = new GHI.Premium.Hardware.RealTimeClock(); and then RTC.SetTime(DateTim time); work as expected?
Suppose the system time and RTC will be synced using Microsoft.SPOT.Hardware.Utility.SetLocalTime(RTC.GetTime())?
Thanks
(btw. When do you expect the firmware fix to be released? Just to let know the customer.)
We do not have a timeline yet for the DateTime crystal fix. But since you will be using RealTimeClock anyway, that fixes that DateTime problem for now.
To set the RTC time:
GHI.Premium.Hardware.RealTimeClock.SetTime(new DateTime(…));
To read the RTC time:
DateTime rtcNow = GHI.Premium.Hardware.RealTimeClock.GetTime();
To update NETMF DateTime with the RTC time:
DateTime rtcNow = GHI.Premium.Hardware.RealTimeClock.GetTime();
Microsoft.SPOT.Hardware.Utility.SetLocalTime(rtcNow);
Thanks John.
S.
One more question: Any tips how to handle Timers or Thread.Sleep()s? They’re not very accurate either, for example Timer set for 1000 ms wakes up at ~976 ms…
I’d suppose it should get better after initiating RTC, but we haven’t noticed any change…
Thanks
You should see a difference. Once RTC is enabled, the board gains 7 seconds every 300 seconds in all of our tests. So over the course of 1 second, the board will gain ~23.3ms which is exactly in line with your measurement of ~976ms.
But if you don’t see a difference, how are you measuring the time taken? Can you show the code?
You also have to remember that the framework isn’t real-time so isn’t guaranteed to be 1000.0ms per timer tick, you’ll still see jitter in the frequency.
Ad Brett: Of course, the customer knows that - what we’re trying to achieve is to force G400-D to work as well as ChipworkX did - which is not really that simple…
Ad John: Good point, I’ll let the customer know that. I don’t know how are they measuring it, but I suppose they’re using oscilloscope to watch and measure signal width Shall I ask them for the code?
If they can get us a small program that shows that time discrepancy repeatedly, we can take a look and try and track it down since we’re not seeing it.
Hello John & others,
so I finally got an answer - it’s just simple 10 row application which uses timer to change a state on output pin every xxxx milliseconds. The measuring is made using memory oscilloscope.
After setting the RTC and using the timer with 1024 ms, the time on oscillo screen is exactly 1000ms. Can’t there be a problem with decimal <> binary?
@ Sebastian Machat - Could you also run that test with more powers of 2 for the timer? Such as 4096, 16384, and 65536ms. See what time the scope says, if it can measure that long.
Was there ever any fix for this in the firmware? Time stamping is very important for my application and I am still seeing major time issues (losing about 10 minutes in 6 hours) or is it still recommended to sync the internal clock to the RTC on a regular basis and the RTC to NTP at least twice a day?