# EspoTek Labrador, a USB board that turns a laptop into an electronics bench

> Labrador is an open source USB device that turns a PC, a Raspberry Pi or an Android phone into an oscilloscope and signal generator, and the repository holds everything behind it: the Qt desktop application, the AVR firmware, the Android app and the KiCad hardware files. The hardware licence is the catch, since it is a non-commercial Creative Commons grant.

**espotek-org/Labrador** — EspoTek Labrador is a USB device that transforms your PC or smartphone into a fully-featured electronics lab.  This repo holds all of the source code!

- Repository: https://github.com/espotek-org/Labrador
- Website: http://espotek.com
- Stars: 1,164 · Forks: 130
- Language: C++
- License: not declared
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/espotek-org-labrador

## One board, three host machines

The EspoTek Labrador is an open source board that turns a PC, a Raspberry Pi or an Android smartphone into a full featured electronics lab bench, with an oscilloscope and a signal generator among the instruments. The important word in that description is open source, because the repository hosts all of the software and the hardware that makes the device possible, not just a driver for a product someone else manufactured. That is unusual for an instrument, and it is the reason a person can read the firmware, rebuild the application and edit the board design. The target user is a learner or a hobbyist who has a computer and a soldering iron and wants real measurement equipment rather than a simulator. The project also points new users at a third party tutorial series, with the reasoning stated plainly, that the author explains everything less clearly than the series does.

## Desktop, firmware, mobile and board files in one tree

The top level listing describes the whole product. Desktop_Interface/ holds the Qt application, and its project file is Desktop_Interface/Labrador.pro, which is what you open in an IDE. AVR_Code/ holds the microcontroller firmware, including the USB_BULK_TEST/Makefile that the documentation points to for a command line build, and the solution file for the vendor IDE. Android_App/ is the phone client, and Librador_API/ is the API directory, spelled that way in the tree. PCB/ holds the hardware design, editable in KiCad 5.0 or later, and labrador_bootstrap_pi/ covers the Raspberry Pi case. There is a libdfuprog/ directory alongside a .gitmodules file, which points to a dependency pulled in as a submodule, and a .clang-format file for the C++ sources. A flake.nix and flake.lock add a Nix build path for people who use it. The design decision worth noting is that the instrument is not one program, it is an application, a firmware, a mobile client and a board, and the repository is arranged so each can be built independently.

## Building the desktop application with Qt

The recommended route for a first build is an IDE, and the project names Qt Creator with the reason that it is the easiest way in. The requirement is Qt 5.15 or later, and on Windows the documentation warns to use the MSVC2019 versions because later releases can introduce compatibility issues. Once Qt is installed, you open the project file and run a three step sequence, Clean All, then Run qmake, then Build All.

The command line route mirrors what the CI workflows in the.github/workflows/ directory do to produce the packages on the releases page, minus the app deployment steps that an individual user does not need. The Linux sequence, run inside the Desktop_Interface directory after the prerequisite packages are installed, is short.

```bash
QT_SELECT=qt5 qmake
make
sudo make install
```

After that the labrador command launches the application. On macOS the prerequisite list is explicit, with Homebrew packages for Qt 5, libusb, eigen and fftw, and a PATH entry for the Qt 5 binaries.

```bash
brew install qt@5
brew install libusb
brew install eigen
brew install fftw
echo 'export PATH="/opt/homebrew/opt/qt@5/bin:$PATH"' >> ~/.zshrc
```

The dependency set is telling. libusb is how the application talks to the board over raw USB, eigen carries the linear algebra, and fftw supplies the fast Fourier transform that a signal generator and a spectrum view need.

## Nix users get a flake, and USB access needs udev rules

A flake.nix is provided for NixOS and Nix users, and it offers two modes. The first builds the package directly and runs the result from the store link.

```bash
nix build
./result/bin/labrador
```

The second enters a development shell where you can build against a local install prefix.

```bash
nix develop
cd Desktop_Interface
qmake PREFIX=$PWD/_install
make -j$(nproc)
make install
./_install/bin/labrador
```

The other half of getting the device to work is permissions, and it is the part that catches new users. Accessing the USB device without root requires udev rules, and on NixOS they go into configuration.nix as extra rules. The rules match on the vendor and product identifiers of the board, with the vendor 03eb and three product identifiers, ba94, a000 and 2fe4, each given MODE 0666.

The rules look like this, matching on the vendor and product identifiers of the board:

ENV{ID_VENDOR_ID}=="03eb", ENV{ID_MODEL_ID}=="ba94", MODE="0666"

On other distributions the same rules arrive as a file, Desktop_Interface/build_linux/69-labrador.rules, which is copied into /etc/udev/rules.d/ and followed by a reload of the udev rules with udevadm. The device then has to be unplugged and plugged back in, because the rules are applied at enumeration time.

## The AVR firmware builds with Atmel Studio or GNU tools

The microcontroller side is a separate build, and the documentation gives two options. The first is the vendor IDE, Atmel Studio 7, where you load the .atsln file found in the AVR_Code directory and press F7 to build. The second is the open source command line AVR toolchain from GNU, and the documentation treats that as a genuine alternative for people who do not want to install a full IDE. The instructions for that path are in the wiki, and there is a troubleshooting section for when a build goes wrong. If the GNU tools are already installed, the documentation points at the firmware Makefile in the AVR_Code/USB_BULK_TEST directory as the starting point, which is the part of the tree that talks to the board over the USB bulk endpoint. The USB_BULK_TEST name is a good hint about what the firmware does at the lowest level, and it is where someone wanting to understand the protocol should start reading.

## Three licences for three kinds of file

The licence section is the most consequential thing in the repository, and it is split three ways. The desktop software files are under the GNU GPL version 3. The microcontroller software files are under the three clause BSD licence, with the exception of those provided by Atmel, which keep their own terms. The hardware files, the schematics and the PCB, are under Creative Commons 4.0 with the BY-NC-SA terms, which is an attribution, non commercial, share alike licence. The consequence is specific and worth stating plainly. You can use, study and modify the software, and you can read, edit and build the board for yourself, but the hardware design carries a non commercial condition, so a company that plans to manufacture and sell a device based on these files is outside what the licence grants. GitHub could not classify the project licence, which is a symptom of exactly this split, and the README is where the terms are written out rather than a single LICENSE file. Nothing here is legal advice, but a decision to commercialise the hardware has to start with that line, not with the code.

## Three release channels and a moving branch

The release naming tells you that the project runs parallel tracks. The tags include stable, dated 2025-11-03, a continuous build dated 2026-09-26, and unified-continuous, named for the Labrador Unified App and marked as a beta, dated 2026-10-13. The repository is not archived and the last push was on 2026-10-19, six days after the beta tag, so the branch is moving faster than the stable channel. The choice between them is a stability decision rather than a feature decision, and the unified app is the one to watch if you want the phone and desktop clients to share a codebase, at the cost of accepting a beta. The extras section shows the community around the device, with community contributed 3D printable cases on Thingiverse and a laser cut plywood case designed by Dave Messink, and the README also points at a project home page for the board itself. The hardware is the scarce part, and the software around it is the part that keeps moving.

## Conclusion

Labrador fits a student, educator or hobbyist who wants a real instrument on a desk without buying a bench oscilloscope, and it fits a hardware tinkerer who wants every layer of the design, firmware and application in one place and can build a board from the KiCad files. It does not fit a company that intends to sell a product built on the hardware design, because the schematics and PCB files are under a Creative Commons licence that forbids commercial use, and it does not fit a user who wants a plug and play instrument, since the board has to be built and flashed. Verify three things first: which release channel you want, since the unified app is still marked as a beta while a continuous build and a stable build also exist, which USB device identifiers your udev rules need to cover, and whether the non-commercial hardware licence fits what you intend to do.

## FAQ

### What is the EspoTek Labrador?

It is an open source USB board that turns a PC, a Raspberry Pi or an Android smartphone into a full featured electronics lab bench, with an oscilloscope and a signal generator among the instruments. The repository holds the software and the hardware files for the whole project.

### How do I build the Labrador desktop application?

With Qt 5.15 or later, open Desktop_Interface/Labrador.pro in Qt Creator and run Clean All, then qmake, then Build All, or on the command line run QT_SELECT=qt5 qmake, make and sudo make install inside the Desktop_Interface directory. On Windows the documentation recommends the MSVC2019 Qt packages.

### Why do I need udev rules to use Labrador on Linux?

The rules give the user permission to access the USB device without root. On NixOS they are added to configuration.nix, and on other distributions the file Desktop_Interface/build_linux/69-labrador.rules is copied into /etc/udev/rules.d/ followed by sudo udevadm control --reload-rules, after which the device is unplugged and replugged.

### What licences does the Labrador project use?

Desktop software is under the GNU GPL v3, microcontroller software except Atmel provided files is under the 3-clause BSD licence, and the hardware schematics and PCB files are under Creative Commons 4.0 with BY-NC-SA terms, which include a non-commercial condition.

## Sources

- [espotek-org/Labrador on GitHub](https://github.com/espotek-org/Labrador)
- [Issues](https://github.com/espotek-org/Labrador/issues)
- [Project website](http://espotek.com)
- [README](https://github.com/espotek-org/Labrador/blob/master/README.md)
- [Releases](https://github.com/espotek-org/Labrador/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/espotek-org-labrador