It’s common for our customers to wonder when their datalogger memory is going to be full, what will happen to their data when the memory is full, and what they should do about it. After all, your data is specific to your application and not reproducible, so you don’t want your data overwritten before you’ve had a chance to save it to your computer and use it. In this brief article, I’ll outline what you need to know about how the memory of your Campbell Scientific datalogger works.
It’s important for you to know that your Campbell Scientific datalogger doesn’t become full and then stop storing new data. Rather, by default, your datalogger's final-data memory (that is, memory for stored data) is organized as ring memory. Each data table is its own ring memory. When the ring is full, oldest data are overwritten by newest data. So, you can think of filling the memory of your datalogger as determining the point in time when any new data you store will overwrite any old data you have.
Note: Look for the FillStop instruction in your datalogger program to determine if your table will fill and stop instead of ringing.
How much time passes before your datalogger memory fills up depends on the following:
If you have a newer datalogger, such as the CR6, you can easily determine the time limit by loading the program and letting the datalogger make the calculation. You can find this information in the program details.
Recommended for You: For help finding the Table Fill Times tab, review the “Tips and Tricks: Details, Details, Details!” newsletter article.
Starting with OS 28, you can also find helpful information in the DataTableInfo table where each data table in the program is assigned a field called DataFillDays.
Note: Table Fill Times statistics cannot be calculated for a CR200(X)-series datalogger.
For data tables that store data based on some condition other than time, it’s not possible for your datalogger to estimate how often the condition will occur. Your datalogger assumes the worst-case scenario, which is that data will be written to conditional tables for every scan. The result is that the DataFillDays field may show a conditional table filling in minutes or hours, but the reality may be that the condition that triggers your data storage is rare and the table will never be filled.
Tip: Define the table size for your conditional data tables by setting a specific number of records rather than allowing your datalogger to auto-allocate table size. Reserve the use of auto-allocation for data tables that store data based only on time.
Recommended for You: For more information about how the DataEvent() instruction is used to store data based on an event rather than a time interval, read the “Tips and Tricks: DataEvent()” newsletter article.
If you have an older array-based datalogger, you can estimate the time to fill the memory by dividing 62,000 by the number of values stored per day. For example, the array 106,239,1400,22.47,22.81,73,10.61 contains 7 data points. If this is being stored every hour, 168 data points (24 hours * 7 data points) would be stored per day. Therefore, 62,000 data points /168 data points per day ≈ 369 days. You may have arrays being stored at several time intervals.
Don’t wait to collect data until your new data is about to overwrite your oldest data. Collect your data as often as you can afford to lose it. Instrumentation in the field is subject to conditions outside of your control. Collecting and reviewing your data is the best way to ensure your system is functioning as designed.
After reading this article, I hope you understand what happens to your data in terms of your datalogger memory filling up. Your data is invaluable to you, and it’s important to copy it from the datalogger to your computer before it is overwritten.
Recommended for You: Need additional help? Review the “Collect Data” tutorial or the "Table Fill Times" segment of the "Connect Window Tutorial."
If you have any questions or comments about the memory of your datalogger, post them below.