Continuous loggers
A continuous logger is a deployed datalogger — a transducer, sonde, or barologger — that records high-frequency readings at a Location over a deployment window. In Erde each deployment is a Logger Stream: the record of who deployed what, where, and for how long. A stream records one or more measured series, and each series is a Logger Channel that holds the time-stamped Logger Readings. This page explains how those three pieces fit together.
The three levels
A logger is modelled as a three-level hierarchy. The stream is the deployment; channels describe what it measures; readings are the values.
- Logger Stream — the deployment record. It belongs to a Location (required and fixed once created) and a Project (also required and fixed), and it may optionally name a Well at that Location. A stream has no Code — its identity is the Location plus the deployment window — but you can give it an optional Name.
- Logger Channel — one measured series on the stream: a Parameter and the Unit it records in, both fixed for the deployment. A stream carries one channel per parameter. Channels are add-or-remove only; there is no edit, because the readings point at the parameter and unit.
- Logger Reading — a single time-stamped value on a channel. Readings are high-volume — a multi-channel stream can hold millions — so they are stored against the channel, not loaded as part of the stream.
Figure: A Logger Stream is deployed at a Location, records one or more Logger Channels, and each channel captures a series of Logger Readings.
The deployment window
A stream records a Deployment Start (required) and an optional Deployment End. While the end is empty the logger is still in the field, and the stream shows as Active. Erde checks the window when you save:
- A deployment end before the start is rejected: "Deployment end cannot be before deployment start."
- A start date in the future is allowed but warned, so a typo such as
2062for2026is caught without blocking a just-retrieved logger. - When a new or edited window overlaps another deployment at the same Location and Well (a null Well matches another null Well), Erde warns rather than blocks — co-located loggers are legitimate, but a forgotten end date is the more common cause.
A stream can also record an optional Reading Interval (seconds) — the nominal cadence the logger was programmed to. This is reference metadata only, not a constraint; leave it empty for an event-triggered logger. Optional Equipment, Deployed By, and Notes fields round out the record.
What a channel measures
A channel pins down the recording schema. Both fields are required:
| Field | Required | Notes |
|---|---|---|
| Parameter | Yes | The monitored parameter. One channel per parameter per stream. |
| Unit | Yes | The unit the channel records in — fixed for the deployment. Pre-filled with the parameter's default unit. |
| Sensor Basis | No | The transducer measurement basis (see below). Meaningful only for pressure or level channels. |
If the unit you pick is not in the same compatibility group as the parameter's default unit, Erde warns and lets you confirm. Adding a parameter that already has a channel is rejected, and a channel that already has readings cannot be removed.
Sensor Basis values
Sensor Basis records how a pressure or level channel relates to atmospheric pressure. It is optional, and channels such as temperature, conductivity, or pH leave it unset.
| Value | Meaning |
|---|---|
| Absolute (raw) | Non-vented transducer measuring water column plus atmosphere — raw and uncompensated; must be barometrically compensated before it is a water level. |
| Vented | Vented or gauge transducer; the reading is already a usable water level. |
| Compensated | An absolute series barometrically compensated in software — a derived water level. |
| Derived | Computed from one or more other channels, such as a calculated elevation. |
Erde stores raw, single-sensor logger series. It performs no barometric compensation itself — Sensor Basis records the measurement basis when you know it, so a level series is self-describing. Reading timestamps are stored as wall-clock UTC and carry no source offset.
This is the universal field convention, and it matters here: a logger programmed to local daylight time repeats one wall-clock hour every fall change-over. Those repeated readings collide on the one-reading-per-channel-per-timestamp rule and are skipped as duplicates.
What a reading holds
Each reading belongs to one channel and carries a timestamp and a value. A channel holds at most one reading per timestamp.
| Field | Required | Notes |
|---|---|---|
| Timestamp | Yes | The reading time. One reading per channel per timestamp. |
| Value | No* | The measured value. May be negative — only finiteness is checked. |
| Invalid | No | A per-channel QC flag that excludes the reading. Defaults to off. |
| Qualifier | No | A short note on the reading (up to 100 characters). |
*A reading with no value must explain the gap: it must be marked Invalid or carry a Qualifier, or Erde rejects it.
Bulk reading ingestion
Readings arrive in bulk — from an Import or from the logger's readings endpoint — rather than one at a time. Erde validates every row first; if any row is malformed (its channel is not on the stream, its timestamp is missing, its value is non-finite, or a value-less row lacks an invalid flag or qualifier), the whole batch is rejected and nothing is stored.
Valid rows are then de-duplicated and inserted in chunks. Erde keeps the first of any repeated (channel, timestamp) pair within the upload, and never overwrites a value already stored for that channel and timestamp — it skips it. Skipped duplicates surface as a warning, never a failure, reporting how many were already stored and how many repeated within the upload. The same insert core backs both the readings endpoint and an import commit, so re-running an upload is safe.
After ingestion you can correct readings on the Readings tab — edit or delete a single point, or use Edit Range to flag a fouled period as Invalid or set a Qualifier across a time window for one channel.
To remove many readings at once, tick the checkbox on each row (or the header checkbox to select the whole page) and select Delete selected (N) above the grid. Bulk deletion is permanent and unavailable while the Site is locked. Unlike domain records, individual readings are telemetry and are not written to the Audit Log. The readings grid loads a page at a time, so selection covers the current page; search, filter, sort, and Export span the whole table (see Working with data grids).
Plan for reading volume
Every reading is one row in the application database, stored against its channel. Deployments in the tens of millions of readings perform well. As the total approaches the hundreds of millions, plan for it: budget the storage, schedule index maintenance with your database administrator, and consult support before bulk-loading an extreme-frequency dataset — for example, sustained one-second logging across many loggers.
This guidance is about database size and write throughput, not display. Charting stays fast regardless of volume, because the Logger Data tool downsamples readings on the server and sends the browser a bounded series however many rows a channel holds.
Where to find loggers
Loggers are managed per Location. Go to Data Management → Sites → (a site) → Locations → (a location) → Loggers. From the Loggers list you create a logger (its Location is fixed by the page), open a stream's Details and Channels tabs, and drill into a channel's Readings tab.
To chart logger data over time, use the Logger Data tool, described in Monitoring charts. It plots a channel's readings across a date range and links back to the Readings tab.