pyfda puts discrete time filter design and fixpoint simulation in a desktop window

A desktop workbench for the filter design loop

pyfda is described as a tool written in Python and Qt for analysing and designing discrete time filters with a user-friendly GUI. That framing matters, because it places the project firmly in the interactive engineering workbench category rather than the library category. You install it, a window opens, and the analysis happens through panels rather than through a function call in your own script. The screenshots in the project documentation show the structure of the tool: a specifications panel, a pole zero panel, a coefficients panel and a fixpoint panel, each with its own plots. Documentation is published on ReadTheDocs, and the repository carries a `docs/` directory along with `spec_files/` for the saved specification format and `ressource/` for bundled assets. The package metadata describes the audience as developers and education, with topic tags for digital signal processing, IIR and FIR, which matches a tool that is expected to be used both at a bench and in a course. Nothing here suggests a server side deployment, and the web port described later in this article exists precisely because the desktop application is not built for that.

Fixpoint simulation is the part most competitors leave out

The interesting technical claim is that fixpoint filter implementations, for some filter types, can be simulated and tested for overflow and quantisation behaviour in the time and frequency domain. That is a real engineering question: a filter whose coefficients look fine in floating point can overflow in fixed point once you quantise it, and the symptom can show up in the frequency domain rather than as an obvious blow up in the time domain. pyfda addresses this with dedicated fixpoint panels that show transient response both in time and in frequency. The machinery behind it comes from Amaranth HDL, which the dependency list names as being there for fixpoint simulation and Verilog export, with the export still marked work in progress and help wanted. That parenthetical matters for expectations: the fixpoint analysis path is the more finished part of the feature, while turning a filter into Verilog is not yet a settled workflow. The required library set also includes numpy, numexpr, scipy at version 1.2.0 or higher, matplotlib at 3.1 or higher, PyQt with Qt5, and Markdown.

Installing with pip and starting the first session

pyfda is a pure Python project with no compilation required, and there is one version for all operating systems on PyPI. Python 3.10 and above is supported, and the required libraries are downloaded automatically if they are missing. The install, upgrade and uninstall steps are:

    > pip install pyfda

    > pip install pyfda -U

    > pip uninstall pyfda

A pip installation creates a start script called `pyfdax` (with an `.exe` suffix on Windows) in the `Scripts` directory of your Python installation, which is expected to be on your path. Starting the tool is then a single command:

    > pyfdax

If you use conda instead, a recipe has existed on `conda-forge` since July 2023:

    > conda install --channel=conda-forge pyfda

Two optional extras are worth knowing about before you start. `mplcursors` adds annotating cursors to plots, and `docutils` enables rich text in the documentation view. For exporting filter coefficients as `.xls` or `.xlsx` files you need `xlwt` and/or `XlsxWriter`, which are listed as optional rather than required. The project keeps `INSTALLATION.md` for further details and `BUILDING.md` for source builds.

Self-extracting archives avoid a Python install but need a chmod on Linux

If you do not want to touch your Python environment at all, binaries are published under the repository releases, both for versioned releases and as an automatically created latest build for each push to the main branch. Self-extracting archives are produced with PyInstaller for 64 bit Windows, OS X and Ubuntu Linux. The described behaviour is unusually specific and worth reading before you rely on it: the archives extract to a temporary directory that is deleted automatically when pyfda is terminated, except in the case of a crash; they do not modify the system apart from two ASCII configuration files and a log file; no additional software needs to be installed; there is no interaction with existing Python installations; and you can overwrite or delete the executable when updating. The one manual step after downloading the Linux archive is making it executable with `chmod 775 pyfda_ubuntu`, since the archive does not carry the execute bit.

A crash therefore leaves the extracted directory behind, which is the only visible residue of an otherwise self-cleaning install. The archive also runs from wherever you unpack it, so where you put it is a decision you make, not one the project makes for you.

The Flatpak route is broken, and the browser port is a different animal

The Linux binaries are also offered as Flatpaks and listed on Flathub, but the project documentation marks both the Flatpak build and the Flathub listing as currently broken. That is an unusually blunt admission, and it means the flatpak path is not a fallback today. Many distributions do have built-in flatpak support, and for the rest the documentation suggests installing it with apt. A web based port does exist, created by a different author: it runs scipy.signal and numpy through Pyodide compiled to WebAssembly directly in the browser, with a modern frontend and Plotly for visualisation. It is described as replicating the main functionality, namely IIR and FIR design, pole zero plots, fixpoint simulation and transient analysis, without requiring a local Python environment. This is the closest thing to a genuine alternative described here, and the difference in approach is clear: the web port trades the native Qt interface and the PyInstaller binary for a serverless, browser based environment, which means no install at all but a different rendering path for the same underlying numeric libraries.

The licence differs between the source and the bundled binaries

The licence situation is the sharpest trap for a project that distributes binaries. The source code is distributed under a permissive MIT licence, but binaries and bundles come with a GPLv3 licence because they contain components with stricter licences. The repository makes this explicit by keeping both `LICENSE.md` and `LICENSE_GPLv3.md` at the top level, and the packaging metadata lists the MIT licence together with `AUTHORS.md` as licence files. The practical consequence for an adopter is narrow and checkable: if you vendor the Python source into your own product, the MIT terms are what apply, while if you redistribute a downloaded Windows, OS X or Linux bundle, the GPLv3 obligations travel with it. That is a packaging decision rather than a licensing judgement about your use, and the answer is not the same for both paths. Anything beyond this observation would be a legal opinion, and the project itself gives you the two files needed to read the terms directly.

Tags lag the branch that carries the actual work

The maintenance picture needs reading from two different signals. The last push to the repository landed on 2026-10-18, so work is still happening on the branch, and the repository is not archived. The tag history is less lively: v0.9.5 was published on 2024-12-22 with fixes for crashes with self-extracting archives and some UI problems, a v0.9.5b1 pre-release came a few days earlier on 2024-12-16, and an automatically built latest artefact is dated 2023-08-07. The default branch is `develop`, while the packaging metadata and the release workflow reference `main`, which is a split worth knowing when you file an issue or track a change. Version numbering is dynamic in the packaging metadata, taken from the source tree rather than hardcoded, and the build backend is setuptools with a declared minimum of 77.0.3. The project is classified as Beta in its metadata and supports Python 3.10 through 3.14. The practical upgrade cost is therefore low for a pip user, who gets the branch content, and higher for a binary user, who is bound by whatever the last tagged archive contained.

Editorial conclusion

Use pyfda when the question is how a filter behaves rather than how to call a filter function: you get pole zero plots, transient response and fixpoint overflow checks side by side, and the pip install needs no compilation. Do not reach for it if you need a library API inside a pipeline, a headless server, or a Verilog flow you can trust today, since the export is still marked work in progress, and avoid the Flatpak build while it stays broken. Before deciding, check that the fixpoint simulation covers the filter type you actually need, since it applies only to some types, and verify the current release rather than assuming a tag exists for the code you are reading on the develop branch.

Frequently asked questions

Official sources

1. chipmuenk/pyfda on GitHub
2. License: MIT
3. Project website
4. README
5. Releases