 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : RTC on MM+ series....
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Howdy.  I thought that the MM+'s RTC would be reasonably accurate given the crystal oscillator on these models. Is that not actually the case? I find that even on MM+ based projects, after several days, the clock is out by quite a bit - five minutes or more over a period of days. This is no real issue for me, as I also have an RTC module on the design, so fixing this is as simple as pressing reset or simply adding an RTC GETTIME command to the main menu screen which will update the clock every time the system goes past the main menu, so this is not causing me any problems, but I am just curious. I know that the RTC on the 170 parts is a little drifty due to the internal oscillator, but I figured that the MM+ series would be much more accurate due to the crystal oscillator reference.  Anyone got any comments? Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
The clock is only as good as the crystal. You can improve the timing by tweaking the value of the capacitors either side of the crystal. Also moving to a warmer climate will change things. If you want to play, my 'timelord' program can be used on the MM+ and MMX to check the timing. It will complain that CLOCKTRIM is not a valid command but you can ignore that error message and the program will run anyway. http://www.thebackshed.com/forum/forum_posts.asp?TID=8294&KW=timelord Output from a MMX first with 5 second timing then with 15 second. The regular hiccups are most likely Windows doing it's thing. The main thing to watch is the log term average. Jim VK7JH MMedit |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
I have found that most computer systems that derive real time from their system clock (and most have a Xtal derived cpu clock) are "drifty". I suppose it is down to the accuracy of the xtals. +/- 100ppm is common (cheaper than 10ppm) and isn't really good enough for real time time over long periods and from tests I have done here, there is a lot of variability between CXOs... even worse with the "traditional" xtal and two caps approach. I bought a couple of these (not these exact models; 6.144000 and 12.288000 MHz - for a precision 1sec gate pulse) and they are pretty damn excellent - expensive but when you need proper precision they can't be beaten for my meager requirements. Have a look at Roman Black's (is he still around?) article for a DIY OCXO here As an aside, I have just completed a project that uses an HC-06 bluetooth module on a MM and it spends days just waiting for something to do. It needs a good RTC but has none! I used the clocktrim to get things close enough (drifts about 20 secs over a day) and the android app transmits the unixtime with each command... the MM gets a clock "just in time" each time and that will be stable enough to hold things together while it is in use. ... string recieved from HC-06 expecting stuff like $U1505057122795! dt$=HumanTime$(Val(Mid$(b$,3,10)))' mask last 3 digits of UT On Error Skip 1:Date$=Left$(dt$,10) ' set the clock (GMT) On Error Skip 1:Time$=Right$(dt$,8) Print Date$;" ";Time$ ... rest of code and the codeflow on the android app does this:  |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Okey dokey, thanks guys. Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
