Anybody have any ideas on a nonvolatile pulse counting totalizer that won't wear itself out?
bte2
Posts: 154
in Propeller 1
I need to accumulate pulses from a flowmeter and keep my count as incorruptible as is possible, to the point of dedicated hardware.
Some ideas I have considered are dedicated EEPROMs (with a wear-leveling strategy applied), zero-power RAMs, battery-backed RAMs, and even ferromagnetic memories which require no power but are expensive and hard to get. The project is also wireless so off-board integrity management is also possible. I'm going for long-term accuracy so I can say with confidence that the count is accurate.
One strategy I have given some thought to is to write the count to several EEPROMs simultaneously and compare them against each other at read time. If one of the chips is different from the others it is flagged as bad. One problem with EEPROMs is that something could happen between the pulses occurring and them actually being written to the EEPROM.
Mechanical counters are out but could be utilized for additional verification.
I'm not looking for code or anything, just points to ponder. I haven't landed on anything solid yet.
Thanks in advance, bryan
Some ideas I have considered are dedicated EEPROMs (with a wear-leveling strategy applied), zero-power RAMs, battery-backed RAMs, and even ferromagnetic memories which require no power but are expensive and hard to get. The project is also wireless so off-board integrity management is also possible. I'm going for long-term accuracy so I can say with confidence that the count is accurate.
One strategy I have given some thought to is to write the count to several EEPROMs simultaneously and compare them against each other at read time. If one of the chips is different from the others it is flagged as bad. One problem with EEPROMs is that something could happen between the pulses occurring and them actually being written to the EEPROM.
Mechanical counters are out but could be utilized for additional verification.
I'm not looking for code or anything, just points to ponder. I haven't landed on anything solid yet.
Thanks in advance, bryan
Comments
In 1995 I was given a tour to a military testing site where we had a technology exchange program setup with the facility. I will not mention the location, but in the midst of "gadgets" they had an electro-mechanical combination lock. Now that doesn't seem that impressive until I tell you that is was made out of silicon and was incorporated on the die of a chip. Alternatively they also had an incremental 128 bit binary counter that was also mechanical in nature but constructed at the silicon level. ... and yes, completely nonvolatile bi-stable mechanical latches.
The funny thing is, if the counter has to be non-volatile then what happens to the counts that are missed when it's powered down? This is where the micro-power battery/cap solution works well, it is always active and basically only needs RAM which is internal to the micro of course. You know that many RTC chips have extra RAM which you could easily use too. The MCP79410 for example has 64 bytes available all nice and safely powered by a battery/cap over I2C.
Peter makes a very good point, you really need a backup-counter, not NV memory.
I think there are RTCs that do exactly that.
Google find this :
["3.1 Event counter mode
Two real time clocks, PCF8583 and PCF8593, have an extraordinary feature. It is the event counter mode which can be selected by setting the appropriate bits in the control register. In this mode the oscillator is disabled and the oscillator input is switched to a high impedance state. This mode can be used to count pulses applied to the oscillator input OSCI. There is no crystal in the circuit and OSCO is left open circuit. The event counter stores up to 6 digits of data. Events are stored in BCD format. The 6 digits use three 8 bit registers (hundredth of a second, seconds, and minutes). D5 is the most significant and D0 the least significant digit. Every digit can contain values ranging from 0 to 9 and thus up to 999 999 events can be stored."]
The reason for the request is that, if I ask it in two years how many pulses it has counted, I have to accept that number without question, even if it was corrupted and therefore meaningless. I have no way to know if the 1,688,242 number that it reports is any good. I also thought about periodically (once an hour or so) write to some sort of ring array so that if anything is amiss at review time it might be obvious.
All I am attempting to accomplish is to cement my confidence that the number reported is real for all circumstances short of a direct lightning strike. This isn't for just one project, it is actually a circuit I would use in a multitude of devices for a multitude of reasons (such as engine/machine hourmeters and cycle counters).
Thanks for the replies, you have given me some food for thought :-)
If you want you could also use wider counters to max out the endurance so each counter counts up to a million before moving on to the next counter. Either way EEPROM is already there and the right software method keeps it simple.
Thank you for that. I stumbled into this which looks very promising:
http://www.cypress.com/file/41651/download
http://www.sandia.gov/mems/_assets/documents/bibliography/3_13MEMS.pdf
I used to work at Honeywell SSEC repairing wafer fab machines. The stuff in the pdf above made us look like we were building Model Ts :-)
In that case, a simple rolling EEPROM store when the pump was on, would give you a slope of numbers you can then check for fit at any time.
At low ~hourly write rates, and a modest sized EEPROM that is a lot of time between over-writes.
I made this neat little discovery back when I was building PC-DOS based control systems. I needed a non-volatile production counter and I didn't want to use the hard drive. IIRC, the hard drives back then would "park" the heads after a period of inactivity so after boot-up, I would let that happen and use the spare RTC locations to keep count of parts produced.
The EEPROM we use for Propeller programs is good for around 1 million erase cycles. When you go to write, start at the beginning and search for the place where the value was last stored. (You can't just store that in EEPROM, because then that pointer gets worn out.) When you find it, erase it and write the update at the next location, circling around to the beginning. This gives you 8 billion write cycles, which is probably enough for most applications.