I am using Arduino Uno (ATMEGA328P). I have a project in which the meter generated a pulse and I will read that pulse and store it in EEPROM if there is no GPRS connectivity as soon as GPRS connectivity is online or stable it will send that data to the cloud and will erase the EEPROM.
I was reading the other topics in this discussion on EEPROM storing and retrieving and got to know something about 100k times writes up only. Exactly what it is? We can write at an address continuously or with 1 or 2-sec delay for 100K times max or it is an overall lifetime.
The counter will be between 00000 - 99999 and again 00000. So if the connection is good the counter which is generating 1,2,3,4,5,6... and at 254 the connectivity is lost. Then 255, 256,257... will be saved in EEPROM. Where 255 will be replaced by 256 then by 257 then by 258 so on...
And when connectivity is stable the last stored number which will be supposed 303 will be taken into account and from there the counter will be sent again to the cloud.
The reference to 100K writes relates to each EEPROM location whatever the frequency of writing. If this looks like being a problem in your project then you can use wear leveling to spread the writes across all of the EEPROM locations although that can be quite complicated to implement
Lucifer22334:
I was reading the other topics in this discussion on EEPROM storing and retrieving and got to know something about 100k times writes up only. Exactly what it is? We can write at an address continuously or with 1 or 2-sec delay for 100K times max or it is an overall lifetime.
The ATmega328 is rated for a minimum 0f 100,000 writes\erases to each location.
UKHeliBob:
The reference to 100K writes relates to each EEPROM location whatever the frequency of writing. If this looks like being a problem in your project then you can use wear leveling to spread the writes across all of the EEPROM locations although that can be quite complicated to implement
I think this can be a problem for my project. Because of the meter which will work continuously and will generate count and I have to store it whenever the GPRS connectivity goes. Also overwriting on the previous data. So this will affect.
Do you have any sort of tutorial or example? so that I can learn and do practical and check.
Lucifer22334:
I think this can be a problem for my project. Because of the meter which will work continuously and will generate count and I have to store it whenever the GPRS connectivity goes. Also overwriting on the previous data. So this will affect.
How often does the GPRS connectivity fail?
How often does the count update?
You don't need to continually store the value, only when there is no connectivity.
Tom...
TomGeorge:
How often does the GPRS connectivity fail?
How often does the count update?
You don't need to continually store the value, only when there is no connectivity.
Tom...
I haven't checked that yet. And yes, the application is the same as you told when the connectivity fails then it has to start storing the values.
I am using a water flow meter which generates a pulse at every liter passed. I am keeping a counter to count the liters of waters. Every counter data will be uploaded to the cloud using GPRS and when there is poor GPRS connectivity or no connection at all then it will start to store data in EEPROM and when the connectivity is gained it ERASE the EEPROM after fetching the last data stored in it and then begins the count from it and starts sending to cloud. EEPROM is used as backup local storage.
Also, there will be multiple nodes with the same water meter(But with a microcontroller which reads the pulse and then send the counter to the Master) and they all will send data to the Master(Which will have GPRS connection and which also sends to the cloud). Master will send every data to the cloud. If there is a connection problem then either Master has to store data or the node will store and send to Master.
Hi,
Thanks for the info.
How often will you be sending GPRS messages?
How far apart are the nodes and do you have a master to collect the data as well as the cloud.
The distance you need to send the GPRS may mean you could use a different network, such as Lora.
Hi,
Why do you need to store the value in EEPROM if the controller is powered up all the time?
If you lose power to the controller, does the water still flow and thus you miss counts?
TomGeorge:
Hi,
Why do you need to store the value in EEPROM if the controller is powered up all the time?
If you lose power to the controller, does the water still flow and thus you miss counts?
Tom...
Just when the GPRS connectivity lost. And also you are right if there is a power failure I am doomed.
I am thinking of using the SD card instead of EEPROM. We can read/write multiple times on it.
And I have one other question, I was reading some articles and there was mentioned that we can read pulse from Analog pin up to 4 digit number like 9999.
Also, every 1 byte in EEPROM can store 0 - 255 values or -127 to 127. so how will it store values greater than 255.
TomGeorge:
Hi,
I haven't used pulse function so I can't comment.
google arduino store large numbers in eeprom
This will give you some examples
Tom..
Yeah, but the issue remains the same that If I want to run this project for a long time it will collapse due to a limit of 100k writing/erasing. And also a complication of writing long integers in EEPROM.
As you now know the project application what do you recommend for storage? EEPROM, SD card, or any other.(As backup storage if GPRS connectivity fails)
You have provided no estimates as to how often you expect GPRS to fail or how long for, so advising on techniques to store data is difficult. For maximum sensible storage I would suggest using an SD card, but as you say that
The counter will be between 00000 - 99999 and again 00000. So if the connection is good the counter which is generating 1,2,3,4,5,6... and at 254 the connectivity is lost. Then 255, 256,257... will be saved in EEPROM. Where 255 will be replaced by 256 then by 257 then by 258 so on...
And when connectivity is stable the last stored number which will be supposed 303 will be taken into account and from there the counter will be sent again to the cloud.
As the values missed during the GPRS down time are not saved and sent, only the last value saved during the down time, then I don't actually see the point of saving anything apart from in a variable, the value of which is sent as soon as GPRS reconnects
What is 100,000? and I can't say about the time it will take to reconnect again. So we to consider the worst-case scenario.
And the as 100k Erase/write is provided over 1-byte storage, we are replacing the data again and again till GPRS connects. so I think its also a point. Huh...There are lots of things to consider.
