Need help.RTC-MCP79410 deviate 11 seconds from standard time source for 19 hours - Page 1
Forum section: electronics / general

author: muthukural001
author_rank: Regular Contributor
timestamp: December 14, 2017, 10:38:53 am
content: Hello all,I am working on RTC-MCP79410. To find out whether My RTC is matched with standard time source, I started My RTC(from 00:00:00) when standard time source is 14:00:00 and stopped at 10:00:00.In the end of test, standard time source completed 19 hours but my RTC was 19 hours and 11 seconds. So, I got to know that my RTC is running fast compared to standard one. To compensate I tried the followingMCP79410 calibration:The chip offers calibration up to ±129 ppm by loading TRIMVAL<6:0> bits. PPM value for my caseCode:PPM = (SecDeviation/Expected sec).1000000Where:ExpectedSec = Number of seconds in chosen periodSecDeviation = Number of seconds gained or lostExpectedSec = 68460 (19 hours)SecDeviation = 11PPM = (11/68460).1000000PPM = 160.677Now, the problem is that My PPM is >129 ppm. Hence, I can not set TRIMVAL<6:0> as this support maximum of 129 ppm when all 7 bits set to 1. Please suggest solution.Note: using 32.768kHz have ±10 ppm frequency tolerance and 6pF load capacitance. Used C1=10pF and C2=12 pF as recommended by Microchip .Regards,Muthu

author: Gribo
author_rank: Frequent Contributor
timestamp: December 14, 2017, 01:42:18 pm
content: 1. Verify that the hardware is within spec.2. What sort of source is it?

author: SparkyFX
author_rank: Frequent Contributor
timestamp: December 15, 2017, 12:30:06 am
content: The current MCP datasheet talks of 1.017 ppm correction ability in Coarse Trim Mode by TRIMVAL<6:0> (2 clocks per bit 128 times per second) when CRSTRIM = 1.Some additional ideas on this:read the PWRFAIL register to check for supply fails in that timecheck if the oscillator was configured as EXTOSC=0supply device with a clock from your reference to exclude crystal as source of error (configure EXTOSC=1 ofc)Consider configuring SQWEN=1 and hooking a frequency counter to MFP to check when the deviation occursverify integrity of I²C communication and general precautions, like pullup resistors, filter cap across Vcc and GNDOther notable things in the data sheet:Quote

author: muthukural001
author_rank: Regular Contributor
timestamp: December 15, 2017, 03:40:40 am
content: Hi Gribo,Thanks. I am using External crystal (part number: ECS-.327-7-34B-C-TR). The crystal used in our board is having 7pF load capacitance which is within 6-9pF as recommended in the MCP79410 datasheet and capacitors(C1 and C2) connected on the crystal pins is 10pF and 12pF respectively. Please refer the attached images from the datasheet for choosing C1 and C2 value for the selected crystal load capacitance.Regards,Muthu

author: muthukural001
author_rank: Regular Contributor
timestamp: December 15, 2017, 03:56:12 am
content: Hi SparkyFX,Right now, I am following the things you quoted. But, for feeding external clock(EXTOSC=1) for MCP79410 instead external crystal(EXTOSC=0), I don't have clock generator to generate 32.768KHz. Is there any other solution?Q2:QuoteIf you mean that the above have solution for 160.677PPM correction,Can you tell me that what value should I load in TRIMVAL<6:0> for this.Please suggest......Regards,Muthu

author: SparkyFX
author_rank: Frequent Contributor
timestamp: December 15, 2017, 12:16:09 pm
content: The formula for that is in the data sheet as well. Next page of the one you mentioned earlier.Going that route depends a bit what you want to investigate further:- crystal oscillator spec/drift (usually not worth it, because as the time nuts on the board can tell, without an "oven" it will drift like crazy with temperature, pressure, vibration, handling etc.), so know your data sheets and don't expect it to be guaranteed for the part at hand, the one you use could be broken/damaged/whatever- ability to compensate for it- overall stability of your setup and system- ability to investigate the source of the problem (tools and procedures used)Those are topics exceeding my experience in metrology. But it's not a bad idea to begin sorting out the usual suspects for most systems.Additionally, the crystal should be positioned closely to the OSC inputs because of the parasitic capacitance in wiring. Maybe shielding or isolating the circuit before the next test reveals some issue with it, like lack of common mode rejection at the inputs.

author: muthukural001
author_rank: Regular Contributor
timestamp: December 16, 2017, 03:39:16 pm
content: Hi,So can I use per minute calibration(CRISTRIM=0) formula for 128 times per second method (CRISTRIM=1).If so, for 160.67 PPM, the hex value is 0x9E which I can't load in TRIMVAL<6:0> as this support maximum value of 0x7F. Hence, I want to neglect 31 PPM(2 sec deviation for 19 hours) and test with 129 PPM.Am I right?Our crystal is very close to the chipQuote

author: SparkyFX
author_rank: Frequent Contributor
timestamp: December 17, 2017, 04:23:51 am
content: That data sheet drives me nuts, it´s all over the place. And i made a mistake, i´ve read 1.017 parts-per-million as 1017 parts-per-million (copied it nonetheless as written) and coarse trim mode is too coarse for your needs... it is 7680 times the normal trim value. But you are able to find that yourself by ... calculating it yourself.I mean to read the clock and the passing of time might also help, give or takeDST(which i understand does not exist in India) and leap seconds, your actual PPM is not +160, but -49847.2 or you shouldn´t use days/dates with DST-switch to measure your PPM, as a full hour might be added or substracted mathematically in one go... without counting the clock ticks provided by the underlying physical process you are supposed to calibrate. The MCP79410 does not know DST or leap seconds... but you did not state what your source is, if you measure 19 hours in what is a 20 hour duration anywhere on the calendar there might be a problem in your procedure.So - what source do you use as a standard? It still is an important question, no matter how ridiculous the answer might be or sound, it helps establishing a context and therefore identify the problem.Which raises the question which value was stored in TRIMVAL and CRSTRIM during time of measurement? I mean it is step 1 of the calibration process to ensure TRIMVAL equals 0 to not fool yourself, but your post left so many question marks that it is hard to tell if this procedure was followed at all. The delay between Step 2 and 3 shouldn´t be part of your measured time deviation as well, obviously.Quote from: muthukural001 on December 16, 2017, 03:39:16 pmMaybe the mess needs to be sorted out:This RTC does actually not count seconds, it counts clock ticks and sums them up to seconds/minutes/hours/days/... based on the assumption that there are 32768 ticks per second and applying things like leap days. You are supposed to use the PPM in EQUATION 5.4 of the MCP79410 data sheet to calculate a TRIMVAL in mode CRSTRIM=0, which is obviously slightly less than the PPM value, as the internal reference has 1966080 clock ticks in a minute of which 2 ticks * TRIMVAL will be added/substracted in mode CRSTRIM=0 once every minute.

author: muthukural001
author_rank: Regular Contributor
timestamp: December 18, 2017, 05:44:39 am
content: Hi SparkyFX,QuoteI am usinghttps://www.time.gov/as reference. For our region in India, it is UTC+5.As you said, DST is not for India.QuoteHere, How did you get -49847.2. Can you explain?.QuoteStep 1:I don't even write TRIMVAL<6:0> once from the time of I got My board. So, I assume TRIMVAL<6:0> is set to 0. To make the things clear, I read TRIMVAL<6:0> to check that it has 0x00 and let you know.Step 2:Here, I load the timekeeping registers to the value next to current minute. For example, if the current time is 11:59:00, I will load the registers with 12:00:00.Step 3:There is one push button switch to start the Oscillator by setting the ST bit. I will press the switch exactly at 12:00:00 (as perhttps://www.time.gov/)Regards,Muthu

author: muthukural001
author_rank: Regular Contributor
timestamp: December 20, 2017, 10:07:11 am
content: Hi SparkyFX,I am waiting for your reply. I have given the inputs you asked. If anything is missed, please let me know.Regards,Muthu

author: SparkyFX
author_rank: Frequent Contributor
timestamp: December 20, 2017, 12:02:16 pm
content: Sorry, I didn´t see the second to last reply.QuoteYou wrote:QuoteThat is...14:00 -> 00:00 = 10 hours00:00 -> 10:00 = 10 hoursSo if your RTC showed 19:00:11, you are off by 1 hour minus 11 seconds. The only reason i know of - next to you making a mistake - in which the standard would complete that time in 19 hours would be at the time of DST shift. Which is why i started talking about DST. But your standard is UTC based and DST is to be calculated as an offset to that, so it should not have affected your standard at all. Without that information it could have been satellite TV or radio and therefore show a DST offset. (they wouldn´t be good references anyway)If you are interested in time transported via network, check out the network time protocol NTP, for linux and windows there are some tools onboard to get you a relatively predictable time base (you could automatically compare output of your circuit with the PC to add some precision). These tools happen to remove transport latency from the time value and correct the PCs internal RTC drift. Imho good enough for applications with a resolution of seconds to calibrate in a reasonable time frame.QuoteThat would be a good starting point, assumptions about the delivery condition (trap for young players) in that critical part of the calibration procedure might be a mistake, as it renders the whole calibration useless. Don´t skip that, Microchip might have a good reason to include it in the data sheet.QuoteSounds legit.

author: muthukural001
author_rank: Regular Contributor
timestamp: December 21, 2017, 04:27:54 am
content: Hi SparkyFX,QuoteSorry, I made mistake on the above.Right one is,14:00 -> 00:00 = 10 hours00:00 -> 9:00 = 9 hoursRegards,Muthu

author: cdev
author_rank: Super Contributor
timestamp: December 21, 2017, 04:48:20 am
content: I have a mini server computer that was sitting in a box unplugged for aroundnine yearswhile I moved cross country. It has been off because the power supply had fizzled out and had an unusual plug and I just didn't get around to fixing it. When I finally plugged it in I was amazed that the clock was still running and actually had the right date, when I figured in the time difference it was only around four hours off!

author: muthukural001
author_rank: Regular Contributor
timestamp: December 22, 2017, 08:52:07 am
content: Hi SparkyFX ,Thanks a lot. My assumption on TRIMVAL<6:0> killed me. When I ran that 19 hours test, OSCTRIM register was set to 0xFF.This means that adding 254 clock cycles for every minute. In this way, for 19 hours, it added extra 9 seconds. Recently, I ran 24 hours test with TRIMVAL<6:0>=0 and My RTC showed 24 hours 4 seconds. This 4 second deviation gives 46.3 PPM.Right now, having SIGN bit set to 0,I loaded TRIMVAL<6:0> with 0x2E (for 46.3 PPM) and running another test.Thanks,Muthu