Skip to main content
Joulescope Python API automated power measurement setup for embedded firmware testing

Automating Power Measurement With the Joulescope Python API

GSAS Engineering · · 7 min read

Beyond Manual Measurement

Manual power measurement, connecting the Joulescope, starting a capture, triggering the device, reading the results from the UI, works well for one-off characterization. But modern embedded firmware development is iterative. Firmware is updated weekly or daily.

Every update can change power consumption, a new peripheral driver, a modified sleep state configuration, an updated radio stack, a bug fix that inadvertently leaves a clock gate open. Without automated power measurement, each firmware update requires a manual measurement session, and regressions slip through until someone notices that battery life has degraded in the field.

The Joulescope Python API (pyjoulescope_driver) transforms the JS220 from a manual instrument into an automated measurement node that integrates into firmware build pipelines, regression test frameworks, and continuous integration systems.

Getting Started With the Python API

Installation

The Joulescope Python package installs via pip on Windows, macOS, and Linux:

pip install joulescope

The package includes the device driver, the data acquisition interface, and utility functions for statistics computation and data export. It requires Python 3.8 or later and a USB 2.0 or USB 3.0 port.

Basic Measurement Script

A minimal measurement script opens the device, configures the sample rate, captures data for a specified duration, and computes statistics:

import joulescope
import numpy as np

with joulescope.scan_require_one(config='auto') as js:
    data = js.read(contiguous_duration=10.0)  # 10 seconds
    current = data['signals']['current']['value']
    voltage = data['signals']['voltage']['value']
    
    print(f"Mean current: {np.mean(current) * 1e6:.2f} uA")
    print(f"Peak current: {np.max(current) * 1e3:.2f} mA")
    print(f"Mean voltage: {np.mean(voltage):.3f} V")

The scan_require_one() function finds the connected Joulescope and opens it. The read() function captures the specified duration of data and returns it as NumPy arrays. From there, standard NumPy and SciPy operations provide any statistical analysis needed.

Energy Per Event

For duty-cycled devices, the key metric is energy per event, the total energy consumed during one complete operational cycle (wake, process, transmit, sleep). The API can compute this by integrating instantaneous power over the event window:

power = current * voltage
energy_joules = np.trapz(power, dx=1.0/js.sample_rate)
charge_coulombs = np.trapz(current, dx=1.0/js.sample_rate)

For devices with periodic events, capture multiple cycles and compute the statistical distribution of energy per event. The mean and standard deviation provide the inputs for battery life projection with confidence intervals.

CI/CD Integration

The Measurement Pipeline

A firmware CI/CD pipeline with power measurement follows this sequence:

  1. Build: Compile the firmware from the latest commit
  2. Flash: Program the DUT with the new firmware (via J-Link, ST-Link, or other programmer)
  3. Stabilize: Wait for the device to enter its steady-state operating mode
  4. Measure: Use the Joulescope Python API to capture a defined number of duty cycles
  5. Analyze: Compute mean current, peak current, energy per event, and sleep current
  6. Compare: Check measured values against the baseline thresholds
  7. Report: Log the results and flag any regressions

Steps 2 through 7 can be automated in a Python test script invoked by the CI system (Jenkins, GitLab CI, GitHub Actions). The Joulescope’s USB interface makes it available to any machine that can run Python and has a USB port, a dedicated test bench, a developer’s workstation, or a CI runner with physical hardware access.

Regression Detection

Define baseline thresholds for the key power metrics:

THRESHOLDS = {
    'sleep_current_ua': 2.5,      # max acceptable sleep current
    'peak_current_ma': 150.0,     # max acceptable peak current
    'energy_per_tx_uj': 500.0,    # max energy per transmission event
}

After each measurement, compare the actual values against the thresholds. If any metric exceeds its threshold, fail the CI step and alert the development team. The alert should include the measured value, the threshold, the percentage deviation, and the firmware commit hash, enabling the developer to immediately identify which change caused the regression.

Trend Tracking

Beyond pass/fail thresholds, log every measurement result to a time-series database or a simple CSV file. Over weeks and months, this data reveals trends: sleep current gradually creeping up as new features are added, energy per transmission increasing as protocol overhead grows, peak current spikes from driver changes. These trends are invisible without continuous measurement and become problems only when a customer reports reduced battery life.

Multi-Device Testing

The Python API supports multiple Joulescope devices connected to the same host. Each device is identified by its serial number, allowing scripts to address specific instruments in a multi-device test setup. This enables parallel testing of multiple DUT variants, multiple firmware configurations, or multiple operating conditions simultaneously.

For production testing, a multi-Joulescope setup can measure every unit coming off the production line, screening for units with abnormal power consumption, a proxy for manufacturing defects such as solder bridges, cold joints, or missing components that alter the power profile.

Data Export and Analysis

The API exports data in JLS (native lossless), CSV, and raw binary formats. JLS files preserve the full 2 Msps data stream and can be reopened in the Joulescope UI for visual analysis. CSV exports are suitable for import into spreadsheet tools or custom analysis scripts. Raw binary exports provide the fastest data transfer for high-throughput automated analysis.

For advanced analysis, the captured data integrates naturally with the Python scientific computing ecosystem, NumPy for numerical computation, SciPy for signal processing and statistical analysis, Matplotlib for visualization, and Pandas for time-series data management.

Why Buy Joulescope From GSAS

GSAS provides Joulescope instruments with INR invoicing and technical support from offices in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR. Our team assists with Python API integration, CI/CD pipeline setup, and measurement methodology for automated power profiling workflows.

Contact sales@gsasindia.com or call +91 80 6590 1783 to discuss your power measurement requirements.

Interested in Joulescope tools?

Talk to our application engineers for personalized tool recommendations.

Stay in the Loop

Get monthly compliance updates, product insights, and engineering best practices delivered to your inbox.

Related Articles

Embedded verification and unit test workflow, illustrating the economics of finding defects early, supported by GSAS Micro Systems in India
Technical Guides

Verification Economics: What a Late Defect Actually Costs, and What the Evidence Really Says

Finding a defect in month 2 instead of month 14 is a budget decision before it is a quality decision. This sets out what the published evidence supports, what it does not, including the 100x multiplier that traces back to a course handout rather than a study, and how an Indian embedded team builds the case on its own numbers.

21 Sept 2026 · 14 min read
Side by side comparison of a 10BASE-T1S multidrop mixing segment, one balanced pair with four nodes on short stubs and a termination at each end, against a point to point star of four separate links into switch ports, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

10BASE-T1S and PLCA: Multidrop Ethernet Explained

10BASE-T1S is the one member of the T1 single-pair Ethernet family that keeps a shared medium, and PLCA is the reconciliation sublayer that stops the nodes on it from colliding. This article covers what IEEE 802.3cg standardises, how the beacon and transmit opportunities schedule a cycle, the node count and segment length figures the OPEN Alliance interoperability test suite works to, and the failure modes that put a segment quietly back into contention while every link still looks up. Written by the GSAS Micro Systems engineering team in India for teams bringing up multidrop segments on the bench.

29 Aug 2026 · 12 min read
Two test paths leaving the same device under test, one into a conformance suite that returns a passed report and one into a partner node that surfaces a field defect, showing why an ECU can clear a published suite and still fail in a vehicle, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

Automotive Ethernet Conformance: TC8 and Testing Above It

Summarising TC8 as a layer 1 to layer 4 suite is wrong in both directions. The public OPEN Alliance ECU test documents run from transmitter distortion up to a SOME/IP chapter with its own standardised test stub, and they contain exactly one time synchronisation test case. This is what those documents enumerate, chapter by chapter, what genuinely lives above their boundary, why a passing ECU can still fail against a partner node, and how much pre-compliance work a Tier-1 in India can honestly do in-house before a test house visit. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 12 min read