Intent to create new SDR ports: comms/ka9q-radio and comms/SoapyRX888

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:

   1. *Port naming:* Are comms/ka9q-radio and comms/SoapyRX888 appropriate
   names and categories?
   2. *Dependencies:* Should librx888 be a separate port, or bundled with
   SoapyRX888?
   3. *Staging:* I plan to develop these incrementally. Is it acceptable to
   submit PRs with basic functionality while continuing development?
   4. *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