Skip to content
#edge computing Open access

waldowda/spec-echem: v0.3.1

Sep 2026 · Zenodo (CERN European Organization for Nuclear Research)

Abstract

This is the first GitHub release since v0.1.0, so it covers everything added in 0.2.0 and 0.3.0 as well. Full detail is in CHANGELOG.md. spec-echem synchronises a potentiostat with a UV-Vis spectrometer for spectroelectrochemistry, so that optical and electrochemical data share one time base. It is still pre-release: the Python API may change between minor versions. The output file format is the exception and is treated as fixed, because downstream analysis depends on its exact column names, ordering and filenames — see docs/data-format.md. Since v0.1.0 A five-tab PyQt5 application replaces the notebook workflow: instrument setup, experiment parameters, a run tab with a live electrochemistry trace, results, and analysis. Analysis inside the application. Doping and dedoping transients are fitted per segment with single-exponential, bi-exponential or stretched-exponential models, over absorbance, current or charge. Each fit reports a mean relaxation time with a 95% confidence interval computed by the delta method on the full covariance matrix, and splits the residual into noise and systematic parts so that models can be ranked. A kinetics ladder plots those timescales against the potential each step was doped to. A density-of-states view derived from the cyclic voltammogram is included but is still under development — it has not been validated against a scan-rate series, and no capacitive baseline is subtracted. The software raises concerns; the scientist decides. A fit that converges but fails a plausibility check keeps every number it produced, drawn dashed in amber and ringed on the ladder. Only a fit that did not converge has nothing to show. Numbers are never withheld because the software is unsure of them. Three potentiostat backends. external (a Gamry sequence file driving the experiment, with hardware triggering), python (a Gamry driven directly through EchemToolkitPy), and autolab (a Metrohm Autolab through its own SDK). Cyclic voltammetry and chronoamperometry work on all three, so a full doping and dedoping sequence runs on either instrument. Instrument setup that reflects the hardware attached. A linearity check ramps the integration time with the reference in place and suggests a working exposure; an opt-in wavelength window crops noisy lamp edges; a non-destructive sample test leaves the reference intact. Each detector's minimum integration time is measured at connect rather than assumed — the two detectors used in this project differ by roughly a factor of 100, and the previous defaults were below the slower one's floor, where the SDK rejects the request outright instead of clamping it. Every run records what produced it. The build identity, the instrument serial numbers, the detector's measured floor and all settings are written to the run's metadata and log, so a data folder says what collected it and not only what was asked of it. Simulated runs label themselves as simulated and cannot later be mistaken for real data. Two logs. An application log opens at launch and is kept indefinitely; a per-run log is written inside the data folder and travels with the data. They answer different questions: "what did I do this afternoon, and where did it go wrong?" versus "how was this folder produced?" Fixed in 0.3.1 The linearity plot's labels no longer run off the canvas or print over each other. The reference lines are now named in the legend, which sits inside the axes at lower right, clear of the ramp. Checked on the instrument PC at its own canvas size — the failure was only visible there, at that canvas width. Validation A full run in Python mode on the Gamry Reference 600 rig, 2026-09-18. The spectrum cadence holds at approximately the requested 100 ms; the exact interval depends on when the spectrometer is read while the potentiostat runs its own sequence, so the timing guarantee is the recorded timestamps, which are hardware-accurate as measured, rather than a perfectly even grid. Connect and linearity checks on the AvaSpec-VRS2048CL-EVO the same day. Four runs on two real films through the Metrohm Autolab backend on 2026-09-11, each finishing cleanly, with the timing measured on a dummy resistor holding unchanged. The output format was checked against the downstream OECT_processing analysis pipeline in July 2026, on data from the Gamry backend. The format has not changed since. 525 automated tests pass (1 skipped, which requires an attached spectrometer). Tested hardware: Avantes AvaSpec-VRS2048CL-EVO and AvaSpec-ULS2048L spectrometers; Gamry Reference 600 and Metrohm Autolab PGSTAT302N potentiostats. Other instruments supported by the same vendor libraries are expected to work within their own limits but have not been exercised. Known limitations The density-of-states view is under development and should not yet be used for published numbers. The live cyclic voltammogram on the run tab can display an occasional point beside the trace; the recorded data is unaffected. Data is written as tab-separated text, one file per segment. An HDF5 output is planned for an upcoming release, to carry a whole run in one self-describing file alongside the existing text format, which stays as the compatibility contract. The vendor libraries (avaspec, EchemToolkitPy) are not installable from PyPI and must come from each vendor's SDK. EchemToolkitPy is currently 32-bit only, which forces the Gamry backend into a separate 32-bit environment from the spectrometer's. A 64-bit release of the Gamry toolkit is expected shortly, and support for it is planned for the next release — one environment will then serve both instruments. Citation Waldow, D. (2026). spec-echem: Spectroelectrochemistry instrument control system (version 0.3.1). Zenodo. https://doi.org/10.5281/zenodo.17221313 That DOI represents all versions and always resolves to the most recent. To cite this release specifically, use the version DOI shown on its own Zenodo record.

View source

Similar papers

#computer vision Review Sep 2017

Agile Software Development Methods: Review and Analysis

This publication proposes a definition and a classification of agile software development approaches and analyses ten software development methods that can be characterized as being "agile" against the defined criterion.

P. Abrahamsson, O. Salo, Jussi Ronkainen et al. · 727 citations · ⚡54
#computer vision Jun 2008

The impact of agile practices on communication in software development

The study shows that agile practices improve both informal and formal communication, but indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication.

M. Pikkarainen, Jukka Haikara, O. Salo et al. · 401 citations · ⚡48
#machine learning Review Open access Oct 2014

Software development in startup companies: A systematic mapping study

The results indicate that software engineering work practices are chosen opportunistically, adapted and configured to provide value under the constrains imposed by the startup context.

Nicolò Paternoster, Carmine Giardino, M. Unterkalmsteiner et al. · 394 citations · ⚡54

Related blog posts

Microsoft Research Blog Oct 6, 2026

What AI gets wrong and what failure teaches us

Jennifer Neville did not want to go into computer science—but that’s exactly where she landed. Neville discusses the starts and stops that led to her professional sweet spot and her work identifying “surprising failures” making it hard for AI to handle complexity.  The post What AI gets wrong and what failure teaches us appeared first on Microsoft Research.

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.