CSM Continuous Measurement and Logging

English | 中文

An example project showing how to build a continuous measurement and logging app with CSM (Communicable State Machine), focusing on decoupling, replaceable modules, and clear data flow.

Why CSM in this repo

• Loose coupling: acquisition, algorithm, logging, and UI communicate by message/status routing, not hardcoded references.
• Hardware replaceability: keep the same public interface and swap data source modules (for example, simulated DAQ ↔ sound card DAQ).
• Scalable design: add new analysis or storage modules without rewriting the existing pipeline.

Architecture overview

This repo composes four roles:

• DAQ Source (Acquisition or SoundInput-DAQ)
• Algorithm (Algorithm)
• Logger (Logging)
• App Orchestrator/UI (UI)

The key data flow:

stateDiagram-v2
direction LR
DAQ --> Algorithm : Acquired Waveform
DAQ --> Logging : Acquired Waveform -> API: Log
DAQ --> UI : Acquired Waveform
Algorithm --> UI : FFT / Power Spectrum

Loading

Module interface docs

Detailed APIs are documented per module (template style):

• Logging module doc
• Acquisition module doc
• SoundInput-DAQ module doc
• Algorithm module doc
• Module docs index

UI variants and differences

This repo provides three UI VIs:

• UI (Beginner).vi: easiest to read, explicit wiring and direct teaching-oriented flow.
• UI (Experienced).vi: balanced readability and abstraction, suitable as daily project baseline.
• UI (The Advanced).vi: most abstract and modular, optimized for reuse/expansion in larger systems.

All three keep the same CSM composition idea; they mainly differ in abstraction level and engineering style.

Compare with Workers style

A concise comparison note is kept in:

• Compare with Workers

References

• CSM Wiki
• CSM Module Repo Template