Newert

SDK · Development

Newert SDK Development Guide

Follow the development sequence from environment selection and permissions through device connection, streaming, event storage, and real-world validation.

Product overview

What does it measure and what do you get?

Mobile

Android · iOS

Review the Flutter-based integration package where provided.

Desktop

Windows · Linux

Build device and stream integration in the provided Python environment.

Validation

Connection · samples · timeline

Before UI polish, verify missing samples, events, and PPG or IMU time alignment.

Designed for these workflows

Android and iOS developers

Implement device connection and measurement with mobile permissions and application lifecycle in mind.

Windows and Linux developers

Implement device connection, processing, and file storage in a Python runtime.

Data engineers

Validate stream schemas, timing, events, storage integrity, and downstream transfer.

How to develop

Implement connection and validation in six steps

Follow version-specific function names but keep state transitions and data validation in this order.

Before you start · Confirm environment and licensed scope first

01

SDK package and README

Prepare the package, samples, and documentation matching the target OS and version.

02

Supported device and firmware

Confirm the device model, firmware, and identifier used for discovery.

03

Development environment

Match the environment required by the product, such as Flutter mobile or Python desktop.

04

License and PRO scope

Confirm whether you will use basic streams or additional PRO waveform and metric outputs.

  1. STEP 1

    Install the package for the target OS

    Install the Android, iOS, Windows, or Linux SDK and run its sample project before integrating it into your application.

    • Record SDK, runtime, and architecture versions
    • Build the sample project
    • Confirm license or configuration file location
    SDK operating-system selection
    Match the package to the target operating system first.
  2. STEP 2

    Configure Bluetooth and OS permissions

    Request Bluetooth and nearby-device permissions before discovery and handle denial, retry, and Bluetooth-off states in the UI.

    • Review permission by OS version
    • Explain denied permission
    • Handle Bluetooth-off state
  3. STEP 3

    Discover devices and manage connection state

    Filter supported devices and explicitly manage discovering, connecting, connected, disconnected, and reconnecting states.

    • Remove duplicate discoveries
    • Store the selected device identifier
    • Handle app exit, background, and reconnection
  4. STEP 4

    Receive PPG and nine-axis IMU streams

    Separate PPG, ACC, Gyro, and Mag in callbacks or streams and preserve receive time and any available device timing.

    • Confirm unit and sample period
    • Review ordering and buffer size
    • Separate UI updates from file storage
  5. STEP 5

    Store events and session files

    Connect participant code, session start and end, and study events to the data timeline and write CSV or your own schema.

    • Exclude direct identifiers
    • Record event value and time
    • Handle normal end and interruption
  6. STEP 6

    Validate under real measurement conditions

    In short and long sessions, verify missing, duplicate, or reversed samples, PPG or IMU alignment, disconnections, and recovery.

    • Compare expected samples with actual rows
    • Compare events with actual task time
    • Check state and file integrity after reconnection

Download

Review a sample file first

Check the file structure, columns, and units before measuring so that you can prepare your analysis pipeline in advance.

Received-data CSV structure

Review an anonymous example that stores PPG, nine-axis IMU, and events on one timeline.

Included fields

Time · PPG · ACC x/y/z · Gyro x/y/z · Mag x/y/z · event

This sample explains structure only. Use the installed SDK README as the source of truth for actual APIs, types, units, and sampling conditions.

Download development CSV sample

Data example

These values are stored in the CSV

The anonymous values below demonstrate the file structure. Scroll horizontally to review every sensor column.

Explicit connection state

Discovery, connection, measurement, disconnection, and reconnection agree in UI and logs.

Signal-specific streams

PPG, ACC, Gyro, and Mag retain their units and timing.

Session and event records

Participant code and study events stay connected to the measurement timeline.

Analysis-ready file

CSV or another file has verified headers, units, missing values, and encoding.

Validation log

Versions, device, conditions, missing samples, and reconnection results are reproducible.

Example received PPG and IMU data

The example keeps PPG, ACC, Gyro, Mag, and study events together on the same time row.

Time (seconds)PPG (dB)ACC x (m/s²)ACC y (m/s²)ACC z (m/s²)Gyro x (°/s)Gyro y (°/s)Gyro z (°/s)Mag x (µT)Mag y (µT)Mag z (µT)event
0.0224119.000-0.1050.8589.727-0.022-0.011-0.010-50.531-7.3488.3980
0.0424121.918-0.1060.9079.721-0.030-0.024-0.010-50.363-7.0788.2980
0.0624124.837-0.1060.9569.716-0.038-0.037-0.011-50.195-6.8098.1970

Separate Basic implementation from PRO additions

Stabilize basic connection and source streams first, then validate PRO features as a separate stage.

Connection state machine
BasicRequired
PRO additionReuse the basic implementation
PPG and nine-axis IMU
BasicSource streams
PRO additionKeep source streams available
Processed waveform
BasicBuild preprocessing
PRO additionHandle additional output according to scope
Analysis metrics
BasicCalculate them yourself
PRO additionHandle metric schema for the purchased product and version

Before contacting support

Check these items in order

01

The sample project does not run

  1. 1.Check supported OS, runtime, and architecture.
  2. 2.Review package and dependency versions.
  3. 3.Check license and configuration file location.
  4. 4.Run the README minimum example unchanged.
02

The device is discovered but will not connect

  1. 1.Disconnect other hosts.
  2. 2.Log connection events and error codes.
  3. 3.Confirm device and firmware support.
  4. 4.Check for duplicate connection objects.
03

The device is connected but samples are missing

  1. 1.Check stream subscription or callback registration timing.
  2. 2.Separate UI rendering from storage bottlenecks.
  3. 3.Log buffer and file-write errors.
  4. 4.Compare expected and received sample counts.

Frequently asked questions

Does the structure on this page match the exact SDK API?

No. This page describes the shared workflow and data structure. Use the README and sample code for the purchased SDK version for exact functions, types, initialization, and error codes.

Should I save received data directly on the UI thread?

We recommend separating live rendering and file storage so they do not delay each other. Validate missing samples using the actual performance and sample period of your target environment.

Should I store device time or computer time?

Check the SDK documentation for available timestamp semantics. Preserve receive time and available device timing according to the analysis requirement and compare them with events.

Are the sample CSV fields always identical?

No. The sample is structural. Actual fields, types, and units can vary by device, app or SDK version, and settings.

Include reproduction details in technical inquiries

A minimum reproduction and environment logs are more useful than an entire codebase for identifying connection or stream issues.

Contact SDK technical support

Continue with another product or solution