Hi all,
I have a design based on the Rabbit RCM3000 core modules and I am
experiencing an issue with one of the modules holding time. It is fitted
with a battery for backup and the voltage was reading 3.0V when I just
checked it.
It seems to lose a lot of time. On Friday I reset the time and this morning
I checked and it was 25 mins slow.
All other modules seem to be fine so I am not sure what is wrong. I have
changed the battery for a new one which is outputting 3.4V and I am using
CR2032 cells.
I am considering changing out the module but it means I will lose all the
recorded data for the last 2 months stored in the battery backed RAM. (It
records electricity usage)
Has anyone else experienced this?
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
Real Time Clock is slow
Started by ●February 28, 2011
Reply by ●February 28, 20112011-02-28
2007 I tried relying on the RTC in the 3700 and found something similar,
eventually gave up leaving the RTC functionality to an external database...
On Feb 28, 2011 12:01 AM, "Dave McLaughlin"
wrote:
> Hi all,
>
> I have a design based on the Rabbit RCM3000 core modules and I am
> experiencing an issue with one of the modules holding time. It is fitted
> with a battery for backup and the voltage was reading 3.0V when I just
> checked it.
>
> It seems to lose a lot of time. On Friday I reset the time and this
morning
> I checked and it was 25 mins slow.
>
> All other modules seem to be fine so I am not sure what is wrong. I have
> changed the battery for a new one which is outputting 3.4V and I am using
> CR2032 cells.
>
> I am considering changing out the module but it means I will lose all the
> recorded data for the last 2 months stored in the battery backed RAM. (It
> records electricity usage)
>
> Has anyone else experienced this?
>
> Dave...
> ---
> Very funny Scotty, now beam down my clothes!!!
> ---
>
eventually gave up leaving the RTC functionality to an external database...
On Feb 28, 2011 12:01 AM, "Dave McLaughlin"
wrote:
> Hi all,
>
> I have a design based on the Rabbit RCM3000 core modules and I am
> experiencing an issue with one of the modules holding time. It is fitted
> with a battery for backup and the voltage was reading 3.0V when I just
> checked it.
>
> It seems to lose a lot of time. On Friday I reset the time and this
morning
> I checked and it was 25 mins slow.
>
> All other modules seem to be fine so I am not sure what is wrong. I have
> changed the battery for a new one which is outputting 3.4V and I am using
> CR2032 cells.
>
> I am considering changing out the module but it means I will lose all the
> recorded data for the last 2 months stored in the battery backed RAM. (It
> records electricity usage)
>
> Has anyone else experienced this?
>
> Dave...
> ---
> Very funny Scotty, now beam down my clothes!!!
> ---
>
Reply by ●February 28, 20112011-02-28
The trouble here is that the design is already done and the PCB's
manufactured. Up until this unit was installed the RTC has been fine so I
suspect the RCM3000 module here. I may just change it out and see what
happens. At least I can do this but for future designs I will add my own RTC
but it does add the cost.
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of Dan Allen
Sent: 28 February 2011 12:04
To: r...
Subject: Re: [rabbit-semi] Real Time Clock is slow
2007 I tried relying on the RTC in the 3700 and found something similar,
eventually gave up leaving the RTC functionality to an external database...
manufactured. Up until this unit was installed the RTC has been fine so I
suspect the RCM3000 module here. I may just change it out and see what
happens. At least I can do this but for future designs I will add my own RTC
but it does add the cost.
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of Dan Allen
Sent: 28 February 2011 12:04
To: r...
Subject: Re: [rabbit-semi] Real Time Clock is slow
2007 I tried relying on the RTC in the 3700 and found something similar,
eventually gave up leaving the RTC functionality to an external database...
Reply by ●February 28, 20112011-02-28
Dave,
Can you verify if the RTC crystal is giving out the correct 32,768KHZ?
Thanks
Duncan
From: r... [mailto:r...] On
Behalf Of Dave McLaughlin
Sent: Monday, February 28, 2011 12:10 AM
To: r...
Subject: RE: [rabbit-semi] Real Time Clock is slow
The trouble here is that the design is already done and the PCB's
manufactured. Up until this unit was installed the RTC has been fine so I
suspect the RCM3000 module here. I may just change it out and see what
happens. At least I can do this but for future designs I will add my own RTC
but it does add the cost.
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of Dan Allen
Sent: 28 February 2011 12:04
To: r...
Subject: Re: [rabbit-semi] Real Time Clock is slow
2007 I tried relying on the RTC in the 3700 and found something similar,
eventually gave up leaving the RTC functionality to an external database...
Can you verify if the RTC crystal is giving out the correct 32,768KHZ?
Thanks
Duncan
From: r... [mailto:r...] On
Behalf Of Dave McLaughlin
Sent: Monday, February 28, 2011 12:10 AM
To: r...
Subject: RE: [rabbit-semi] Real Time Clock is slow
The trouble here is that the design is already done and the PCB's
manufactured. Up until this unit was installed the RTC has been fine so I
suspect the RCM3000 module here. I may just change it out and see what
happens. At least I can do this but for future designs I will add my own RTC
but it does add the cost.
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of Dan Allen
Sent: 28 February 2011 12:04
To: r...
Subject: Re: [rabbit-semi] Real Time Clock is slow
2007 I tried relying on the RTC in the 3700 and found something similar,
eventually gave up leaving the RTC functionality to an external database...
Reply by ●April 23, 20112011-04-23
Are you talking about the time read DIRECTLY from the RTC chip?
Or the time reported in Rabbit time functions?
If you do a lot of interrupt handling on the unit and interrupts are disabled for a too long, you can miss rtc interrupts which makes it look like the clock is running slow. If this is the case, when you reboot, the clock will catchup to the correct time.
Or the time reported in Rabbit time functions?
If you do a lot of interrupt handling on the unit and interrupts are disabled for a too long, you can miss rtc interrupts which makes it look like the clock is running slow. If this is the case, when you reboot, the clock will catchup to the correct time.
Reply by ●April 23, 20112011-04-23
Yes, the time reported by the Rabbit time functions.
You are right, when I reboot the time is now correct. I was thinking of
forcing a RTC read every hour as it doesn't go out by many seconds in that
time. It is minutes every few days.
I suspect it is because of the CAN bus controller interrupt handling that
the issue exists. I do what I need to read the device as quick as possible
and store the results in a fifo and then process the data in the main task.
The interrupt should only be firing once per second as I only have 1 sensor
sending data. I'll look into the code in the interrupt and see if I can
optimise it to be quicker.
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of Joey
Sent: 23 April 2011 12:08
To: r...
Subject: [rabbit-semi] Re: Real Time Clock is slow
Are you talking about the time read DIRECTLY from the RTC chip?
Or the time reported in Rabbit time functions?
If you do a lot of interrupt handling on the unit and interrupts are
disabled for a too long, you can miss rtc interrupts which makes it look
like the clock is running slow. If this is the case, when you reboot, the
clock will catchup to the correct time.
You are right, when I reboot the time is now correct. I was thinking of
forcing a RTC read every hour as it doesn't go out by many seconds in that
time. It is minutes every few days.
I suspect it is because of the CAN bus controller interrupt handling that
the issue exists. I do what I need to read the device as quick as possible
and store the results in a fifo and then process the data in the main task.
The interrupt should only be firing once per second as I only have 1 sensor
sending data. I'll look into the code in the interrupt and see if I can
optimise it to be quicker.
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---
From: r... [mailto:r...] On
Behalf Of Joey
Sent: 23 April 2011 12:08
To: r...
Subject: [rabbit-semi] Re: Real Time Clock is slow
Are you talking about the time read DIRECTLY from the RTC chip?
Or the time reported in Rabbit time functions?
If you do a lot of interrupt handling on the unit and interrupts are
disabled for a too long, you can miss rtc interrupts which makes it look
like the clock is running slow. If this is the case, when you reboot, the
clock will catchup to the correct time.
Reply by ●April 23, 20112011-04-23
One interrupt per second is a pretty low rate, but I suspect that the handler is
taking too long to complete, so in the end, interrupts are disabeld too long for
the rtc. My guess is you are moving a lot of data.
Periodically resyncing the rtc with system time is a good solution, especially if you can live with the small amount of drift.
For this application, I would also consider allowing the interrupts to nest. In your CAN handler, you can re-enable the interrupts before it completes (after handling the critical functions). This way the rtc can interrupt your handler to bump the time. If you are using uCOS, this is tricky, but otherwise, it is straight forward.
Periodically resyncing the rtc with system time is a good solution, especially if you can live with the small amount of drift.
For this application, I would also consider allowing the interrupts to nest. In your CAN handler, you can re-enable the interrupts before it completes (after handling the critical functions). This way the rtc can interrupt your handler to bump the time. If you are using uCOS, this is tricky, but otherwise, it is straight forward.
Reply by ●April 28, 20112011-04-28
On Apr 23, 2011, at 12:22 AM, Dave McLaughlin wrote:
> You are right, when I reboot the time is now correct. I was thinking of forcing a RTC read every hour as it doesnt go out by many seconds in that time. It is minutes every few days.
>
My advice on timekeeping is to leave SEC_TIMER as-is, and keep a "skew" variable that tracks the difference in time between SEC_TIMER and the actual time.
This ensures that timeouts based on SEC_TIMER don't get screwed up. Code that needs to track elapsed time can continue using SEC_TIMER and code that needs to know the time/date can use (SEC_TIMER + skew).
I think there's some code in the HTTP client library or sample that demonstrates this technique.
-Tom
> You are right, when I reboot the time is now correct. I was thinking of forcing a RTC read every hour as it doesnt go out by many seconds in that time. It is minutes every few days.
>
My advice on timekeeping is to leave SEC_TIMER as-is, and keep a "skew" variable that tracks the difference in time between SEC_TIMER and the actual time.
This ensures that timeouts based on SEC_TIMER don't get screwed up. Code that needs to track elapsed time can continue using SEC_TIMER and code that needs to know the time/date can use (SEC_TIMER + skew).
I think there's some code in the HTTP client library or sample that demonstrates this technique.
-Tom
