MacOS Tahoe 26.1 Users - Attention:

Changes to USB support in Tahoe version 26.x cause sdrtrunk to fail to launch. Do the following to install the latest libusb and create a symbolic link and then use the nightly build which includes an updated usb4java native library for Tahoe with ARM processor. There may still be issue(s) with MacOS accessing your USB SDR tuners.

brew install libusb --HEAD
cd /opt
sudo mkdir local
cd local
sudo mkdir lib

Next, find where brew installed the libusb library, for example: /opt/homebrew/Cellar/libusb/HEAD-9ceaa52/lib/libusb-1.0.0.dylib Note: the folder "HEAD-9ceaa52" is the version stamp for HEAD when you installed from it.

Finally, create a symbolic link from the installed library to the place where usb4java is expecting to find libusb (/opt/local/lib/libusb-1.0.0.dylib)

sudo ln -s /opt/homebrew/Cellar/libusb/HEAD-9ceaa52/lib/libusb-1.0.0.dylib /opt/local/lib/libusb-1.0.0.dylib

sdrtrunk

A cross-platform java application for decoding, monitoring, recording and streaming trunked mobile and related radio protocols using Software Defined Radios (SDR).

• Help/Wiki Home Page
• Getting Started
• User's Manual
• Download
• Support

Figure 1: sdrtrunk Application Screenshot

Download the Latest Release

All release versions of sdrtrunk are available from the releases tab.

• (alpha) These versions are under development feature previews and likely to contain bugs and unexpected behavior.
• (beta) These versions are currently being tested for bugs and functionality prior to final release.
• (final) These versions have been tested and are the current release version.

Download Nightly Software Build

The nightly release contains current builds of the software for all supported operating systems. This version of the software may contain bugs and may not run correctly. However, it let's you preview the most recent changes and fixes before the next software release. Always backup your playlist(s) before you use the nightly builds. Note: the nightly release is updated each time code changes are committed to the code base, so it's not really 'nightly' as much as it is 'current'.

Minimum System Requirements

• Operating System: Windows (32 or 64-bit), Linux (32 or 64-bit) or Mac (64-bit, 12.x or higher)
• CPU: 4-core
• RAM: 8GB or more (preferred). Depending on usage, 4GB may be sufficient.

Creating a Release (Maintainers)

Releases are built and published automatically by the Release GitHub workflow whenever a version tag is pushed to the repository.

1. Update projectVersion in gradle.properties to the new version, following the naming convention described in that file (e.g. 0.6.2-alpha-1, 0.6.2-beta-1 or 0.6.2).
2. Commit and push the change to master.
3. Create and push a tag that matches the version with a leading v:

git tag v0.6.2-beta-1
git push origin v0.6.2-beta-1

The workflow then:

• Verifies that the tag matches projectVersion in gradle.properties and fails if it does not.
• Builds and tests the code, then creates the release zips for Linux, Mac and Windows (x86-64 and aarch64).
• Creates a GitHub release titled Version <version> with auto-generated release notes (a "What's Changed" list of the PRs merged since the previous version tag), and attaches the six zip files plus a SHA256SUMS checksum file.
• Marks tags containing a dash (alpha and beta versions) as pre-releases. Tags without a dash become full releases.

If the workflow fails part way through, fix the problem and re-run it from the Actions tab. It resumes from the draft release left behind. It won't modify a release that has already been published. To rebuild a published release, delete the release and the tag on GitHub, then push the tag again.