DIY Hour Meter - RTC or EEPROM?

[GabYoung92]

Hi All,

We are trying to make a hour meter to keep track of the power on time of individual panels of a LED screen. 
We have also looked at the already made hour meter for engines but want to customize it a little - Mainly not need the induction pickup - and want to make it look pretty (Splash Screen, Possible Serial number on screen)

I have already toyed with an Arduino and an OLED screen on the bench and its doing exactly what we want.  (Picture Attached) but need to add days to the equation - Not hard to do

Now the question I have is how to store the data/count.

1) Use a RTC with a 3V backup battery
      - Only want it to count up when power is applied - not counting up all the time as what a RTC normally does
2) Doing basic counting using the processor and save it into the EEPROM
     - Worried about writing too much data and destroying the EEPROM
3) Combining the two above somehow
     - Maybe store the last time in the EEPROM and just add the previous count and current RTC count (Reset RTC to 0 when first turned on)
     - Have to consider how to quickly write the time to the EEPROM as the power is turning off. - External power sense pin that fired an interrupt on power down?

Looking for suggestions to solve this.

[Mr.B]

One way:
Cypress F-RAM
https://nz.mouser.com/ProductDetail/877-FM24CL04B-G

You will never exceed the write endurance.
I have used the linked part above in a couple of projects that needed good write endurance for a small quantity of data.
The one above is the cheapest they make. 4kbit of storage for about NZD 2.40

It works very similar to I2C EEPROM, however there are a few subtle differences.
There is a library for Arduino available, just search github for FRAM.

Edit: Here is the library I used: https://github.com/sosandroid/FRAM_MB85RC_I2C

[Bassman59]

One way:
Cypress F-RAM
https://nz.mouser.com/ProductDetail/877-FM24CL04B-G

Yep, FRAM all the way. Trivially easy to read from and write to, and an infinite write endurance so no need for wear leveling or any of that. Yes, they are more expensive than EEPROM in a similar size.

[Mr.B]

...and an infinite write endurance ...

Yip, basically infinite...

The spec says 10^14 writes.
Writing every 1ms it should last a fraction over 3170 years.
Should outlive your product warranty...   

[Ian.M]

OTOH I believe FRAM uses destructive reads, so if you loose power during a read before the chip has completed its write-back cycle, you can corrupt the location you were reading. 

Also, if you are basing the hourmeter  on Arduino hardware, the usual 16MHz ceramic resonator isn't that accurate (and the 8MHz internal oscillator is even worse) so you may well want a RTC anyway, for more accurate timekeeping.  It also gives you the option to  display total elapsed time as well as power-on time, or actual time of last powerup etc. which would aid diagnostics of panels with an unreliable supply.

Probably the best option is a RTC module and log the total hours (as seconds) to the battery backed RAM in the RTC chip.   If you keep three copies of the count in the RTC RAM  incrementing them all once a second,  you don't have to worry about maintaining power to the Arduino to do a write on loss of power:

If it looses power during a write, one count will be corrupted.  The other two counts should be unaffected.   They will have one of two possible values, either the previous count, or the current count (which is the previous count + 1).  Therefore on powerup, read the three counts and reject any that aren't within 1 count of the other two, then take the highest remaining.   There is a vanishingly small probability of this occasionally adding 1 second to the total, if the second count gets corrupted and just happens to end up with a value one more than the correct total, but I doubt you'd ever see in practice.

If possible use a RTC with a squarewave output pin, and connect it to an input pin of your MCU, as it makes the code a lot easier if you set the RTC to output 1Hz at powerup and simply update the counts each time you see that pulse.

Using uint32_t counts, it can run for 136 years before the counts overflow, by which time, you, me, the Arduino and the RTC battery will all be long dead so its definitely somebody else's problem.

[CJay]

Expanding a little on what Ian.M said, I'd use a Dallas DS1307, it haspulse per second output to increment a counter on the Arduino which i would write to the DS1307 battery backed SRAM (56 Bytes) so plenty of space to store a minute or hour count for 'on time' plus it does all the timekeeping for you and outputs a conveniently formatted time and date message if asked.

If data permanence after battery removal is important then write the content back into a small, cheap EEPROM once per day.

Or you could write the timekeeping routines yourself and play with FRAM (attractive idea, i need an excuse to play with an FRAM)

[Ian.M]

Yes, but if you do go the FRAM route, you *NEED* to avoid power loss during a FRAM read, as handling the possible data corruption gets really really fugly - you cant even check if the data is corrupted unless you can guarantee the power is good as reading the other copy of the data to check against could corrupt that also.

It doesn't take much hold-up time for the write-back to compete - the decoupling caps are probably good enough, but it means you will have to monitor Vin for a power fail interrupt.

The DS1307 solution doesn't need any special hardware except an Arduino and a RTC breakout or shield.

[CJay]

The DS1307 solution doesn't need any special hardware except an Arduino and a RTC breakout or shield.

Absolutely, it'd be my solution too, the FRAM would only be to satisfy my curiosity about them.

[David Hess]

Fix the regulated supply to the microcontroller so that power loss is detected and plenty of holdup time is available.  This is made much easier to do if only the necessary circuits are powered after power loss which includes the microcontroller and external memory if used but not the display.  With this done, plenty of holdup time will be available to use the non-volatile memory technology of your choice including EEPROM.

I designed something similar long ago using just a PIC with integrated EEPROM but if I wanted the highest reliability, I would use two external non-volatile memory ICs on separate interfaces.

If a retention time of weeks to months is acceptable, it is also feasible to use micropower CMOS SRAM and some microcontrollers have this function integrated.

The storage requirements are low enough that hand made core memory could be used.

[GabYoung92]

Wow thanks for all the replies!
I did not know about FRAM - Looks very interesting!

We don't really care about accuracy or loosing a second here or there - Hell to be honest we only care about updating the count into memory every minute.  So if the unit is powered on for 59 seconds then turned off and we lose the 59 seconds - We won't loose any sleep.
These counters are going to go onto the back of every panel in huge LED screens. - They will be off far more than on - and when they are on, they stay on.
This is so we can monitor wear between the panels - IE we don't mix up a 5 hour panel with a 50 hour panel. 

We will be converting this into a small PCB (can do easily) and then epoxy/waterproof them up as they can and most likely be exposed to the elements (Water/Dust)

- Like the 1Hz output from the RTC - But we really don't care what the REAL time of day is - only the second counting. - Maybe we can get rid of the battery and ust use the RTC chip as a divider for the crystal.
- Can easily build in reserve capacitance into the board and use an external power fail sense line to run a shutdown procedure.  (Running only the processor and memory (Be that EEPROM or FRAM) on backup capacitance)
- Updating the count even min to the internal EEPROM of an avr of 100,000 cycles gives about 69.44 days... Fram looks nice but would have to take into account the destructive read.

Thanks for all the suggestions!

[mikeselectricstuff]

EEPROM would be doable as you don't need super high precision - once per minute would probably be fine. With a 1M write endurance eeprom that would be about 2 years if you only used one location.
You can use multiple locations to spread the wear - many ways to to this.
e.g. if value is 3 bytes, use the middle byte to indicate which of 256 locations to use for the LSbyte - that gives 256M writes with trivially simple code. 
And you probably don't even need 1 minute resolution.

[Ian.M]

I am confident you can store the count reliably and redundantly in under 16 bytes.  The ATmega328P has 1K of EEPROM.  That's 64 times more than you need so, even with a crummy wear levelling algorithm you could extend your 69.44 days to over 12 years.  If you use a smart wear levelling algorithm that uses more locations for the most frequently changing bytes (i.e low byte and checksum), over 50 years would be possible, while still maintaining that 1 minute update rate.

You may want to consider using an eInk display, e.g. https://www.waveshare.com/wiki/1.54inch_e-Paper_Module
as they continue to display the last image even when power is removed, which could be a major advantage for an elapsed hour counter.

[mikeselectricstuff]

I am confident you can store the count reliably and redundantly in under 16 bytes.

Definitely, but if you have the space available, using it can allow the code to be very simple and less likely to be buggy.

e.g. for my  idea of using 256+2 bytes  to get 256x endurance :

At powerup , or to read the count : 
count2=readee(0x100);
count1=readee(0x101);
count0=readee(count1);

Every minute :

if (++count0==0) {
   writeee(0x100,++count1);
   if(count1==0) writeee(0x101,++count2);
  }
writeee(count1,count0);  // write byte0 at location [byte1]