1a90eaf6c6
PDU header format 0x15 is the generic unconfirmed data header; unconfirmed multi-block trunking control (UMBTC) is only its trunking control SAP (61/63) use. PDUHeaderFactory built a plain PDUHeader for every 0x15 header and PDUMessageFactory sent every such sequence to createUMBTC(), so outbound unconfirmed IP data (SNDCP RF UNCONFIRMED DATA with SAP 0, 4 or 6) was logged raw as PDU HEADER FORMAT:UNCONFIRMED MBTC UNCONFIRMED VENDOR:STANDARD TO LLID:n DATA BLOCKS:4 MSG:4100450000... while the confirmed equivalent (format 0x16) was decoded as IPPKT with its LRRP / ARS payload. - PDUHeaderFactory: build a PacketHeader for a 0x15 header whose SAP is UNENCRYPTED_USER_DATA, PACKET_DATA or SNDCP_PACKET_DATA_CONTROL. Other SAPs, including trunking control 61/63, keep the plain PDUHeader. - PDUMessageFactory: route a 0x15 sequence whose header is a PacketHeader through createPacketData(); everything else stays on the UMBTC path. No payload changes are needed: PacketMessage already sizes unconfirmed data blocks at 12 octets, and the header fields it uses (SAP, pad octet count, data header offset) sit at the same bit positions in the confirmed and unconfirmed headers. The ARS RegistrationAcknowledgement parser only reads the extension octet, so the 5-octet trailer (0x04 + 32-bit time) some systems append does not affect it. Adds PDUMessageFactoryTest, built from two unconfirmed PDUs captured on a Motorola P25 Phase 1 system (ARS registration acknowledgements to UDP port 4005, one with the trailer), plus header routing checks for SAP 0/4/6, SAP 61/63 and the confirmed 0x16 header. Co-authored-by: csmith_ai <carrottop@gmail.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
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).
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 or64-bit), Linux (32 or64-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.
- Update
projectVersioningradle.propertiesto the new version, following the naming convention described in that file (e.g.0.6.2-alpha-1,0.6.2-beta-1or0.6.2). - Commit and push the change to
master. - 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
projectVersioningradle.propertiesand 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 aSHA256SUMSchecksum 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.