Filtration & analytics
Self-tuning filtration without a hand-designed filter
Process the same ordered signal in instant, bounded-latency and offline modes. Recover gaps and one-step predictions; add analytics, attributed events, channel health and a System Passport without per-channel filter design.
Three output modes — instant, low-latency and offline. The current introductory allowance is shown in the account.
Use Filtration & analytics for recurring or live sensor streams
The technical material below remains available for engineering review; this summary is the shortest route to deciding whether the product fits.
- Best for
- Ordered numeric sensor channels processed repeatedly or as a live stream.
- You provide
- Time, named channels and the latency mode required by the application.
- You receive
- Cleaned outputs in live, delayed and offline modes; analytics are available on higher plans.
- Buying model
- From €29/month. Current included processing is shown before payment; no automatic overage.
The problem
Classical filters force a trade-off you shouldn't have to make
Break on hard signals
On the listed multi-tone and chirp cases, the tested classical configurations increased RMSE. This result applies to those configurations and protocol, not to every possible implementation of the method.
Days per channel
A signal model good enough to filter with is a project of its own — and it has to be redone for every new channel, every drift, every noise level.
Raw noise or over-smoothing
Teams ship features on raw noise, or smooth away the physics they came for. The frontier below is the third option.
Latency and quality
Three modes on one stream
All three outputs use the same stream with different data-access and delay budgets. The separate 32-case real-waveform table reports mode-specific averages and non-applicable cases. Choose a delay compatible with the task; algorithmic delay is not a cloud response-time guarantee.
| Output | Latency | What it sees | When to use it |
|---|---|---|---|
| instant | 0 · zero-lag | past + current only | Applications requiring no future sample in the algorithm; transport and compute time remain separate |
| low-latency | 120 samples | A delayed estimate with the declared 120-sample alignment; see response delay_samples | streaming pipelines — most of the quality at bounded delay |
| offline | retained tail | maximum context | batch re-processing and archival cleanup at maximum quality |
Physical streams hold up to 264 synchronized response channels; logical stream groups shard up to 4,096 channels. The free tier meters by processing volume, not channel count. Formats, limits and warm-up behavior — in the API quickstart.
On non-stationary signals the streaming low-latency output even beats the offline batch (moving-spectrum chirp at 20 dB: +5.3 vs +0.0 dB) — per-block adaptation tracks a moving spectrum that a single global method choice cannot.
Earlier latency summary — separate test set
The earlier site summary reported +6.1 dB for delayed versus online output and +1.9 dB for offline versus delayed output, with a reported range of +0.8 to +14.7 dB. The aggregation inputs for that summary are not supplied here. These figures are not derived from the 32-case real-waveform table and must not be treated as a guarantee across signals.
Evidence
Where classical filters add error, the filter keeps cleaning
RMSE reduction relative to the noisy input; higher is better. Negative gain means the tested configuration added error on that case. The hard-signal configurations below and the 32-case real-waveform suite are separate tests; do not combine their averages.
Full real-waveform tables — 16 datasets, 32 cases, three output modes, plus the honest abstentions — on the Benchmarks page.
| Hard signal · SNR | Best classical filter | Low-latency (120 samples) | Offline |
|---|---|---|---|
| Multi-tone vibration · 30 dB | −6.5 dB (others to −26.5) | +8.3 dB | +12.5 dB |
| Multi-tone vibration · 20 dB | −9.3 dB (others to −16.7) | +8.2 dB | +12.8 dB |
| Multi-tone vibration · 10 dB | −5.3 dB | +8.2 dB | +12.8 dB |
| Chirp (moving spectrum) · 20 dB | −11.7 dB (others to −20.1) | +5.3 dB | +0.0 dB |
| Chirp (moving spectrum) · 10 dB | −7.4 dB (others to −10.1) | +4.9 dB | +0.2 dB |
Performance depends on the signal and configuration. Compare methods within one protocol, with the same input, reference and delay budget.
Do-no-harm on clean input
When there is nothing to remove, the low-latency and offline outputs leave a near-clean signal essentially untouched (RMSE at the input floor) — a principled record/replay criterion backs the denoiser off to the raw signal instead of over-smoothing it.
Prediction and gap recovery
The same stream also serves one-step prediction and recovery of missing samples — for feature pipelines that need every tick filled, and for post-processing archives with dropouts.
Filtration + Analytics
Four connected views of the same stream
Many monitoring stacks show isolated scores and charts. NLSYS keeps event evidence, lagged predictive dependencies, channel health and the System Passport on the stream you already process, so an engineer can move from “something changed” to the channels and evidence that explain the alert.
Attributed events
Per-channel state and named event types such as outlier, level shift, regime change and frozen channel, with the evidence available for that event. Attribution is evidence, not a claim of physical causation.
Predictive dependency graph
Directed, lagged relationships that improve prediction, with strength and delay. The graph is explicitly predictive; causal interpretation requires separate experimental evidence.
Channel health
Integrity, calibration state, frozen fraction, restarts and recurring residual structure that can indicate a sensor or model-quality problem.
System Passport
A batch report from an accumulated stream or uploaded time series: identified dynamic terms, validation, channel behaviour, predictive dependencies, residual evidence and explicit limitations.
Analytics uses the same integration as the filtration workflow. It does not turn predictive dependencies into causal claims, and it does not include a standalone NDC model compile.
System Passport
A technical report for the measured system
The Passport consolidates the model evidence that can be supported by the accumulated data. It is designed for review, hand-off and inclusion in an engineering record.
| Section | What it reports |
|---|---|
| Dynamic terms | Identified per-channel terms and components, numerical fit and uncertainty where estimable. |
| Channel behaviour | Evidence for linear, nonlinear, periodic, memory, non-stationary or changing-variance behaviour. |
| Predictive dependencies | Directed lagged relationships that improve prediction, separated from common system-wide modes. |
| Residual evidence | What remains unexplained after the identified model and where recurring structure remains. |
| Validation | Held-out performance and the conditions under which the reported conclusions were evaluated. |
| Limits | Insufficient data, weak identification and conclusions that the evidence does not support. |
Two different outputs. The System Passport reports on an accumulated stream or uploaded time series. A separately purchased NDC compile delivers an executable model with its own Nonlinearity Passport, support boundary and verifier.
One integration
From cleaned signal to evidence without a second monitoring stack
Filtration and analytics share the same ordered data, channel names and stream history. That reduces the hand-off between cleaning, monitoring and reporting.
| Need | Common separate workflow | Filtration & analytics |
|---|---|---|
| Signal quality | Separate cleaning and monitoring pipelines | Cleaned outputs and health from one stream |
| Event review | Score first, manual correlation later | Named event with available channel evidence |
| Cross-channel context | Built in another analysis tool | Lagged predictive dependency graph |
| Engineering record | Charts assembled manually | System Passport generated from the same data contract |
| Reproducibility | Depends on saved scripts and settings | Versioned request, deterministic processing and report artifacts |
Who it's for
Clean features, clean instruments, clean archives
Data & ML teams
Filtered features and a fast model-free baseline before — or instead of — building and maintaining your own denoising models.
R&D and instrumentation
Cleaner signatures from test rigs and precision instruments without hand-designing a filter per channel and re-tuning it per experiment.
Data refinement
Batch re-processing of accumulated data at offline-max quality: cleanup, gap recovery and one-step prediction on the archive you already have.
Filtration & analytics plans
Start with cleaning. Add analytics or more volume when needed
Every plan includes a current processing allowance shown in the account. Additional processing uses prepaid top-up balance; there are no automatic overage charges.
Basic filtration
Three output modes, one-step prediction and gap recovery.
- Adaptive signal cleaning
- Online, bounded-latency and offline output
- Processing allowance shown before purchase
Filtration + Analytics
Signal cleaning plus predictive evidence and reports.
- Everything in Basic
- Attributed events and channel health
- Lagged predictive dependencies and System Passport
Team
The same filtration and analytics functions with a larger monthly allowance.
- Filtering + Analytics
- Higher included processing volume
- Lower effective usage price than ordinary top-ups
Team is the higher-volume Filtration & analytics plan: the same Filtration + Analytics functions with a larger monthly processing allowance and a lower effective usage price.