On Tue, Sep 16, 2025 at 8:58 PM Larry Gadallah <[email protected]> wrote: > Hello FreeBSD ports maintainers, > I'm announcing my intention to create two new ports in the comms category for > Software Defined Radio (SDR) applications: > > Port 1: comms/ka9q-radio > > Description: Multichannel SDR platform based on fast convolution and IP > multicasting > Upstream: https://github.com/ka9q/ka9q-radio > License: Mixed (primarily BSD/MIT compatible) > Author: Phil Karn (KA9Q) > > Overview: ka9q-radio is a high-performance SDR platform that can > simultaneously demodulate hundreds of channels using efficient fast > convolution algorithms. It's designed for applications requiring many > concurrent receivers (APRS gateways, monitoring systems, etc.). The software > already has partial macOS support, providing a BSD-compatible foundation for > FreeBSD porting. > > Dependencies: FFTW3, Opus, Avahi, ncurses, various SDR hardware libraries > Challenges: Requires adaptation from systemd to rc.d service management > > Port 2: comms/SoapyRX888 > > Description: SoapySDR module for RX888 wideband SDR receivers > Upstream: https://github.com/cozycactus/SoapyRX888 > License: Open source (investigating specific license) > Author: CozyCactus > > Overview: SoapySDR backend module for the RX888, a popular $200 16-bit SDR > with up to 64 MHz bandwidth. This would complement existing SoapySDR modules > already in ports (SoapyRTLSDR, SoapyHackRF, SoapyAirspy). The module already > works on macOS via Homebrew, demonstrating BSD compatibility. > > Dependencies: SoapySDR, libusb, librx888 (may need separate port) > Challenges: RX888 has a somewhat fragmented driver ecosystem > > Questions for the Community: > > Port naming: Are comms/ka9q-radio and comms/SoapyRX888 appropriate names and > categories?
Looks good :-) No minus in the name is preferred but there are ports with minus too :-P > Dependencies: Should librx888 be a separate port, or bundled with SoapyRX888? If this can serve other applications / ports as standalone library then yes it can be a separate port, if only used by SoapyRX888 then it can be bundled. Depending on how big is the package libs may be just part of bigger bundle. > Staging: I plan to develop these incrementally. Is it acceptable to submit > PRs with basic functionality while continuing development? Yes, assuming basic port is operational, and new working features are added with updates these may come as port options / flavors :-) > Conflicts: Are there any existing ports or planned developments that might > conflict? > > Development Timeline: > > Phase 1: ka9q-radio interactive components (control, monitor) - leveraging > existing macOS compatibility > Phase 2: ka9q-radio daemon (radiod) with rc.d service management > Phase 3: SoapyRX888 module porting from macOS implementation > Phase 4: Integration testing and optimization > > I have experience with both SDR hardware and FreeBSD systems, and I'm > committed to maintaining these ports long-term. The SDR community has > expressed significant interest in FreeBSD support for these tools. > > I welcome any feedback, suggestions, or offers of collaboration. Please let > me know if there are any concerns or recommendations before I begin > development. > > Related Existing Ports: > > comms/SoapySDR (framework) > comms/SoapyRTLSDR, comms/SoapyHackRF, comms/SoapyAirspy (similar backends) > comms/rtl-sdr, comms/hackrf (hardware support) > math/fftw3 (dependency) > > Thank you for your time and consideration. > Best regards, > -- > Larry Gadallah, NM7A/VE6VQ lgadallah AT gmail DOT com > PGP Sig: 0247 9AD1 FFA8 2E35 0B5B E387 F9B8 2875 FDFE DB69 Thank you Larry and Have Fun! Let me know if there is anything to test and how to test :-) You should find all necessary hints in the Porter's Handbook :-) https://docs.freebsd.org/en/books/porters-handbook/ NM7A 73 SQ7MHZ / Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
