pslab-python: instrument access to the Pocket Science Lab, gated by permissions you do not control

What the device is, and what the library actually does

The Pocket Science Lab is an open hardware platform from FOSSASIA, and this repository is the Python library for talking to it. The goal described is an open source hardware device, open on all layers, with software applications usable for experiments by teachers, students and scientists.

The instrument list is what makes it more than a serial library. The device provides an oscilloscope, a waveform generator, a logic analyzer, a programmable voltage and current source, and a component for controlling robots with up to four servos. Each of those is exposed as Python objects.

The library has a second consumer that shapes its API. It is also used as the backend component of the PSLab GUI, which means the interface you script against is the interface the desktop application uses internally. That is a reasonable design for consistency and a real constraint when the GUI's needs and yours diverge.

There is a clear division of responsibility in the install step: if you only want the device as an acquisition source without a display, pslab-python is sufficient on its own. A GUI means installing the separate PSLab app repository as well.

Installation is one pip command with three platform notes

The package is on PyPI and installs like any other Python library:

$ pip install pslab

The three notes after that command are the practical part, because a successful install is not the same as a working device.

Linux users must either install a udev rule by running pslab install as root, or be a member of the dialout group, for the library to communicate with the device. That is a permission problem at the operating system level, and the library ships a command to fix it rather than leaving you to write a rule.

Windows users with the PSLab v6 device must download and install the CP210x Windows Drivers from the Silicon Labs website. That is a serial bridge driver, which is why it is a device-specific instruction rather than a generic one.

If you want a GUI rather than scripting, the PSLab app is a separate repository with its own instructions. Installing both is the full desktop setup.

The validation snippet tells you what success looks like

The README gives a two step check. Plug in the device and confirm both LEDs light up, then run a specific piece of code and expect no errors:

from pslab import ScienceLab
psl = ScienceLab()
capacitance = psl.multimeter.measure_capacitance()

That snippet is short and reveals the whole API shape. The entry point is the ScienceLab class, instruments are attributes of it, and each instrument exposes named methods. multimeter.measure_capacitance() is a measurement call rather than a property read, which fits hardware where the act of measuring is the operation.

Because the check is a real measurement rather than a connection test, it exercises the whole path: permissions, serial port, device firmware and the instrument itself. If it prints a capacitance value, the stack is working.

A CLI entry point exists and doubles as the permission fix

pyproject.toml declares a console script:

[project.scripts]
pslab = "pslab.cli:cmdline"

So installing the package puts a pslab command on your PATH, and that command is what the Linux note refers to when it tells you to run pslab install as root. A CLI that only exists to set up udev rules would be unusual; here it is part of the package's supported surface.

The project metadata is worth noting too. The name is pslab, the description and version are dynamic, and the build backend is flit_core at a version from 3.4 up to but not including 4, which is what reads those dynamic fields out of the module.

The declared floor is Python 3.8, and the classifiers list only Programming Language :: Python :: 3 with an Operating System :: OS Independent entry and a Development Status of Production/Stable. That is a deliberately loose platform statement for a package that plainly has per-platform caveats, since it also documents Linux group membership and a Windows driver requirement.

The dependency set is small and versions differ between the two requirement files

The runtime dependencies in pyproject.toml are four: pyserial, numpy, scipy, and mcbootflash at 8.0.0 or newer. The first three are the obvious ones for a serial instrument library doing numeric work.

The separate requirements.txt disagrees with pyproject.toml on the mcbootflash floor, requiring 4.1.0 or newer where the project metadata requires 8.0.0 or newer. Both files exist at the root. If you are installing from the declared project metadata, pip resolves against the 8.0.0 floor; if you install with the requirements file directly, you may get an older mcbootflash than the project intends. That discrepancy is worth resolving before you pin anything.

Requirements are also split by purpose: doc-requirements.txt for the documentation build and lint-requirements.txt for linting, with tox.ini orchestrating environments and a.bandit file configuring the security linter.

Maintenance, and what GPL-3.0 means for a teaching tool

The recent releases are 3.1.1 on 2025-01-05, 4.0.0 on 2025-02-19 and 4.0.1 on 2025-06-16, with the last push on 2026-08-15. So the code is still being worked on, but the published releases are from 2025, which for a device library is a consideration when you are matching versions across a lab's machines.

The version 4.0.0 release in February 2025 is a major version jump, so anything written against the 3.x API is looking at a breaking change.

The licence is GPL-3.0, with copyright stated as FOSSASIA 2014 to 2021. For a library used in teaching material this is usually the right choice: if you modify the library and distribute it, the derivative carries the same licence. The practical consequence for a university or a lab is that a script wrapping pslab and shared outside the institution is distributing a combined work, and if you need to keep that closed, GPL-3.0 is the wrong licence for the decision rather than a technical obstacle.

Support channels are the issue tracker, a Gitter room and a mailing list, with the FOSSASIA Code of Conduct applying to all of them.

Where pslab-python is the wrong tool

Without the device, the library is inert. Every instrument is a command over a serial connection to specific hardware, so there is no simulation path in the README and no mock backend. If you want to develop the code before the hardware arrives, or you want to test instrument logic in CI, this library gives you nothing to run.

The second boundary is scope of instruments. The documented set is an oscilloscope, waveform generator, logic analyzer, programmable voltage and current source, and four servo outputs. Anything outside that, such as general sensor logging across arbitrary channels, is not what this library describes.

The third is deployment. GPL-3.0 plus a udev rule that must be installed as root plus a vendor serial driver means the library is straightforward in a teaching lab where you own the machines, and awkward inside a managed institution image or a locked-down device fleet. For a classroom pilot the friction is acceptable; for a fleet rollout it is a packaging project.

Editorial conclusion

Adopt pslab-python if you have PSLab hardware and want to script measurements in Python rather than click through a GUI, and you need multimeter, waveform generation, logic analysis or servo control. Do not adopt it as a general purpose acquisition library, because every instrument call is a command to a specific device reached over a serial port, and it is not useful without the hardware. Verify first that your platform can open the device: Linux needs pslab install as root or membership of the dialout group, and a PSLab v6 on Windows needs the CP210x drivers from Silicon Labs.

Frequently asked questions

Official sources

1. fossasia/pslab-python on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases