NetReceiver is based on the idea of keeping clients very simple and putting as much processing as possible into NetReceiver, i.e., "the cloud." Please read the general help first.

Raw data

Wherever possible, clients should send raw sensor data, leaving the processing and interpretation of data to be performed in the cloud by the associated sensor object. By adhering to this principle, historical raw data remains available to future software versions.

Example 1

An analog voltage reader should report the raw ADC value without interpreting the value.

Example 2

A turbidity sensor utilizes two luminance values. A raw turbidity metric can be derived from the average of the two raw luminances, which can in turn be passed through a calibration lookup table to produce a calibrated turbidity metric. The client should however just report the two raw luminance values without further processing.

Example 3

An sensor computes wave period and wave height from accelerometer data. The accelerometer output values should be sent as a binary data with the computation performed in the cloud.

Software defined

A corollary to the "raw data" principle is that sensor functionality should be defined in software, i.e., as so-called software-defined sensors. For example, a trivial example is the conversion of an analog value into a voltage, by means of multiplying a scale or adding an offset. The software-defined approach becomes more powerful with complex measurements, such as turbidity, where multiple software operations are required. The software-defined approach facilitates the reuse of a single stream of raw data by multiple sensors. Furthermore, improvements to sensor functionaltiy can be retrospectively applied to historical data.

Compression

Compress data only when it is impractical to send raw data. Where practical, prefer lossless compression over lossy compression.