Data Logger Storage Does Not Have a Fixed Duration

Data logger storage cannot be translated directly into a fixed number of days. Retention depends on usable space, the complete size of each stored record, and how often the logger writes that record.

The first calculation should therefore use the actual configuration, not the capacity label alone. The result then needs to be checked against measured storage growth and a controlled outage-and-recovery test.

Start with what must survive the outage

Define the required outage window before choosing a retention number. A remote station may need to preserve measurements through a short cellular interruption, a longer network repair, or the period between scheduled site visits. Those scenarios do not automatically require the same local buffer.

Also define what preserve means. Is the requirement limited to raw values, or must the recovered dataset include timestamps, channel identity, units, status fields, quality indicators, and processed results? The acceptance requirement should describe the records that must appear at the server or dashboard after reconnection, not merely confirm that the memory device was not full.

Why data logger storage is not a duration

The official GEOVOS 1000 Datalogger page lists 8 GB of storage, up to 12 sensor slots, RS485, cellular connectivity, and a monitoring platform. These specifications establish a relevant system context, but 8 GB by itself does not define the retention window.

One configuration may store a small number of parameters at a relaxed interval. Another may write more channels, device status, and processed values much more frequently. Hioki’s data-logger guide connects recording duration with memory capacity, sampling speed, and channel count. The actual rate at which complete records are stored still has to be checked for the intended configuration.

The usable data allocation may also be lower than nominal capacity because the operating system, database, indexes, internal logs, and reserved space consume part of the medium. Use an approved documented value or measure it on the intended unit. Do not apply another vendor’s overhead percentage to GEOVOS.

Define the complete stored record

A sensor result may look like one number on a dashboard, while its stored record contains more fields. These can include a record number, measurement timestamp, channel identifier, unit, processed value, communication state, quality flag, and database or file structure.

The Campbell Scientific documentation on datalogger intervals provides one product-specific example in which a table record includes a record number, timestamp, and processed variable values. The exact format is not universal. The practical rule is to measure or document the complete record written by the implementation rather than count only the raw numeric payload.

Time fields matter during recovery as well. Keep the measurement time distinguishable from server receipt time and dashboard display time, with an explicit time zone or offset from UTC. Otherwise, delayed records can be mistaken for new observations or placed in the wrong order.

Separate capture, storage, and transmission intervals

Three intervals can control different parts of the system:

Interval	Question	Storage implication
Sampling or scan	How often is the sensor read?	A reading is not necessarily written as a separate stored record.
Logging or storage	How often is a record committed locally?	This is the main multiplier for periodic record consumption.
Transmission	How often are records sent to the server?	This affects backlog age and size but may differ from the logging interval.

A logger might scan a sensor every few seconds, calculate an average, and store one record at a longer interval. Another implementation may retain every reading. Review the program, data table, or exported configuration before selecting the interval used in a storage calculation.

Calculate the estimate, then measure it

For fixed-size records, use a transparent relationship with consistent units:

Retention = floor(usable storage bytes / average complete-record bytes) x logging interval

The calculation needs four inputs:

1. storage bytes actually allocated to measurement records;
2. average bytes in one complete record;
3. the record-writing interval in seconds or minutes;
4. every table, file, or record stream running at the same time.

The NexSens X2 storage example shows how usable capacity, parameter count, bytes per log, and logs per day can be made explicit. Its numerical values belong to that product. The useful part is the audit trail: every input is visible and can be replaced with project-specific evidence.

If record length, compression, indexing, or file rotation varies, measure storage growth under the intended configuration. Record available space, file changes, record counts, restarts, and rotation events over a representative period. Then estimate:

Measured retention = usable storage / average storage growth per day

Repeat the measurement after changing channel count, logging interval, record format, firmware, or enabled functions. Set the margin from the project’s retention policy and failure scenario rather than copying a universal percentage.

Treat full memory and power loss as different failures

The design needs a documented answer for the full-memory condition. A logger may stop writing, overwrite the oldest records, rotate files, or raise a storage alarm. The public GEOVOS pages do not define that behavior, so confirm it through approved documentation and a test on the actual configuration.

Power autonomy is a separate limit. Unused storage cannot preserve new measurements after the power system can no longer support the sensors, logger, and write operations. A monitoring site survey should connect the retention requirement with power, communications, environmental exposure, access, and maintenance planning.

Validate the backlog after reconnection

Local storage does not prove that records will automatically reappear in the correct order on the dashboard. Recovery needs acceptance criteria and traceable evidence.

1. Record the disconnection time, configured intervals, and the last record received by the server.
2. Remove the communications path while keeping the sensors and logger powered.
3. Confirm that local record counts or storage growth continue during the agreed outage.
4. Restore connectivity and measure how long the backlog takes to transfer.
5. Compare logger, server, and dashboard records for timestamps, order, gaps, duplicates, and final totals.
6. Repeat the test for restart, power interruption, or near-full storage when those cases are within the acceptance scope.

Use unambiguous timestamps with an explicit UTC relationship, such as the format described in RFC 3339. If the implementation uses an at least once delivery mode such as MQTT QoS 1, the MQTT 5.0 specification notes that duplicates can occur. This does not establish that GEOVOS uses MQTT; it explains why the actual project’s protocol and deduplication behavior belong in the test.

Bring configuration evidence to the system review

A useful retention review needs the channel list, complete record format or export, sampling and logging intervals, usable storage allocation, measured daily growth, full-memory policy, power design, and outage-test results. A capacity figure without those inputs cannot support a defensible offline window.

The Argatech guides to data logger versus PLC roles and environmental telemetry architecture provide further context for device responsibilities and the end-to-end data path.

Fortuna Argatech can help review sensors, dataloggers, intervals, power, connectivity, dashboards, and acceptance tests as one system. When contacting the Fortuna Argatech team, include the actual configuration and the outage duration the system must handle so that the retention recommendation can be traced to the project requirement.