F46J50 RTCC with internal oscillator

[WrySun]

Hi Guys,

I'm using the built in RTCC on a PIC18F46J50 with the internal oscillator. The RTCC ticks fine but runs 5% slow, making it lose ~3-4 seconds every minute.

Using the calibrate argument to setup_rtc() I'm able to make the clock run 2.64 seconds faster per month, but not per minute.

I don't need a very accurate clock for my application. Up to a few seconds error per day would be acceptable, but here the clock is drifting more than an hour per day. I'm aware the internal oscillator is not as accurate as an external clock crystal but can it really be this inaccurate or am I doing something wrong?

I've tried switching between these fuses but I couldn't measure any difference:
RTCOSC_INT RTCC uses Internal 31KHz Oscillator as reference source
RTCOSC_T1 RTCC uses Secondary Oscillator as reference source

Any idea what the issue could be? Can I improve the accuracy somehow? Would a software RTC be more accurate? Thanks in advance.

[temtronic]

two options I've used...

#1) There's a 'zero drift SW RTC' in the 'code library'. Easy to use,reconfigure for your PIC and it works....... used it for years until...

#2) use an external RTC/EEPROM module.All of them work and you can get a 'more accurate' one(DS13332 ??). The external EEPROM was a 'bonus' for me,saved some calibration data for one project. They also have a small amount of battery backed RAM in the RTC (used for timed triggers or comparisons ). I stored data there(3-4 bytes) when AC power failed.

so at least two options for you.

[Ttelmah]

Fundamental problem.
The standard RTC code/hardware, is written to run off a clock at 32768 Hz.
The internal RC oscillator is 31000 Hz...

Difference is just under 6%.

The T1 option requires an external 32768 Hz crystal.

It's an insane part of the chips. If you look at the datasheet, it says
(Section 16), that the RTC module 'requires external 32768 Hz crystal'.
Requires.
Yet it allows you to select he internal RC, that is 31000 Hz....

The adjustment range for the oscillator is much less than is needed
to bring the 31KHz oscillator to 32768Hz.

Basically if you try to use the internal oscillator you will always get a clock
that is about 5.5% slow.

[WrySun]

Thank you, that explains it. I successfully switched to using Neutone's software RTC instead, posted by ckielstra here:
https://www.ccsinfo.com/forum/viewtopic.php?t=26177

[Ttelmah]

Yes.
Sensible solution. Provided you accept that there could be a small drift
with temperature etc., this is the way to go.
It has always been a source of annoyance, that given they build the
hardware to use 32768, why the calibrated internal oscillator can't give
this frequency seems 'odd'.....

[WrySun]

With the software RTC I measured the drift to be 9 seconds too fast per hour at room temperature, which is sufficient accuracy for my application.

[Ttelmah]

For your test chip, you could obviously apply a tweak using the adjustments
to get it closer. Each count is about 0.03%. So -9 counts ought to be close.

[temtronic]

One of life's mysteries ! 31000 internal xtal when 32768 has been the standard for DECADES !
I've never understood why all internal xtals aren't 'binary',ie easily divisible by 2 to give accurate timing of clocks.
It'd make UARTS run better, timers run better....even if you had to trim,at least timings would be close to begin with.
I'm kinda surprised you can't buy a PIC with a high speed 'binary' clock inside.It'd give perfect timing and free up TWO I/O pins ! Seems clients always want ONE other 'add on,please'....

[Ttelmah]

Er. Most of the internal clocks are 4MHz, 8MHz, 16MHz etc..
So nice binary values.
It is only the high accuracy low frequency clocks where they have this
silly 31000Hz value.
Answers on a postcard for these!...
Also the 7.37MHz value for the master for the DsPIC's
There must presumably be some simple path in their semiconductor
layout that makes these their defaults, otherwise not a lot of sense here....