From Newsgroup: muc.lists.freebsd.ports
--000000000000445a2d063eefb549
Content-Type: text/plain; charset="UTF-8"
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
--000000000000445a2d063eefb549
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><p class=3D"gmail-whitespace-normal gmail-break-words= ">Hello FreeBSD ports maintainers,</p>
<p class=3D"gmail-whitespace-normal gmail-break-words">I'm announcing m=
y intention to create two new ports in the comms category for Software Defi= ned Radio (SDR) applications:</p>
<h2 class=3D"gmail-text-xl gmail-font-bold gmail-text-text-100 gmail-mt-1 g= mail--mb-0.5">Port 1: comms/ka9q-radio</h2>
<p class=3D"gmail-whitespace-normal gmail-break-words"><strong>Description:= </strong> Multichannel SDR platform based on fast convolution and IP multic= asting<br>
<strong>Upstream:</strong> <a class=3D"gmail-underline" href=3D"
https://git= hub.com/ka9q/ka9q-radio">
https://github.com/ka9q/ka9q-radio</a><br> <strong>License:</strong> Mixed (primarily BSD/MIT compatible)<br> <strong>Author:</strong> Phil Karn (KA9Q)</p>
<p class=3D"gmail-whitespace-normal gmail-break-words"><strong>Overview:</s= trong> ka9q-radio is a high-performance SDR platform that can simultaneousl=
y demodulate hundreds of channels using efficient fast convolution algorith= ms. 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.<=
<p class=3D"gmail-whitespace-normal gmail-break-words"><strong>Dependencies= :</strong> FFTW3, Opus, Avahi, ncurses, various SDR hardware libraries<br> <strong>Challenges:</strong> Requires adaptation from systemd to rc.d servi=
ce management</p>
<h2 class=3D"gmail-text-xl gmail-font-bold gmail-text-text-100 gmail-mt-1 g= mail--mb-0.5">Port 2: comms/SoapyRX888</h2>
<p class=3D"gmail-whitespace-normal gmail-break-words"><strong>Description:= </strong> SoapySDR module for RX888 wideband SDR receivers<br> <strong>Upstream:</strong> <a class=3D"gmail-underline" href=3D"
https://git= hub.com/cozycactus/SoapyRX888">
https://github.com/cozycactus/SoapyRX888</a>=
<strong>License:</strong> Open source (investigating specific license)<br> <strong>Author:</strong> CozyCactus</p>
<p class=3D"gmail-whitespace-normal gmail-break-words"><strong>Overview:</s= trong> SoapySDR backend module for the RX888, a popular $200 16-bit SDR wit=
h up to 64 MHz bandwidth. This would complement existing SoapySDR modules a= lready in ports (SoapyRTLSDR, SoapyHackRF, SoapyAirspy). The module already=
works on macOS via Homebrew, demonstrating BSD compatibility.</p>
<p class=3D"gmail-whitespace-normal gmail-break-words"><strong>Dependencies= :</strong> SoapySDR, libusb, librx888 (may need separate port)<br> <strong>Challenges:</strong> RX888 has a somewhat fragmented driver ecosyst= em</p>
<h2 class=3D"gmail-text-xl gmail-font-bold gmail-text-text-100 gmail-mt-1 g= mail--mb-0.5">Questions for the Community:</h2>
<ol class=3D"gmail-[&:not(:last-child)_ul]:pb-1 gmail-[&:not(:last-= child)_ol]:pb-1 gmail-list-decimal gmail-space-y-1.5 gmail-pl-7">
<li class=3D"gmail-whitespace-normal gmail-break-words"><strong>Port naming= :</strong> Are <code class=3D"gmail-bg-text-200/5 gmail-border gmail-border= -0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-pre-wra=
p gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]">comms/= ka9q-radio</code> and <code class=3D"gmail-bg-text-200/5 gmail-border gmail= -border-0.5 gmail-border-border-300 gmail-text-danger-000 gmail-whitespace-= pre-wrap gmail-rounded-[0.4rem] gmail-px-1 gmail-py-px gmail-text-[0.9rem]"= >comms/SoapyRX888</code> appropriate names and categories?</li>
<li class=3D"gmail-whitespace-normal gmail-break-words"><strong>Dependencie= s:</strong> Should librx888 be a separate port, or bundled with SoapyRX888?= </li>
<li class=3D"gmail-whitespace-normal gmail-break-words"><strong>Staging:</s= trong> I plan to develop these incrementally. Is it acceptable to submit PR=
s with basic functionality while continuing development?</li>
<li class=3D"gmail-whitespace-normal gmail-break-words"><strong>Conflicts:<= /strong> Are there any existing ports or planned developments that might co= nflict?</li>
</ol>
<h2 class=3D"gmail-text-xl gmail-font-bold gmail-text-text-100 gmail-mt-1 g= mail--mb-0.5">Development Timeline:</h2>
<ul class=3D"gmail-[&:not(:last-child)_ul]:pb-1 gmail-[&:not(:last-= child)_ol]:pb-1 gmail-list-disc gmail-space-y-1.5 gmail-pl-7">
<li class=3D"gmail-whitespace-normal gmail-break-words"><strong>Phase 1:</s= trong> ka9q-radio interactive components (control, monitor) - leveraging ex= isting macOS compatibility</li>
<li class=3D"gmail-whitespace-normal gmail-break-words"><strong>Phase 2:</s= trong> ka9q-radio daemon (radiod) with rc.d service management</li>
<li class=3D"gmail-whitespace-normal gmail-break-words"><strong>Phase 3:</s= trong> SoapyRX888 module porting from macOS implementation</li>
<li class=3D"gmail-whitespace-normal gmail-break-words"><strong>Phase 4:</s= trong> Integration testing and optimization</li>
</ul>
<p class=3D"gmail-whitespace-normal gmail-break-words">I have experience wi=
th both SDR hardware and FreeBSD systems, and I'm committed to maintain= ing these ports long-term. The SDR community has expressed significant inte= rest in FreeBSD support for these tools.</p>
<p class=3D"gmail-whitespace-normal gmail-break-words">I welcome any feedba= ck, suggestions, or offers of collaboration. Please let me know if there ar=
e any concerns or recommendations before I begin development.</p>
<h2 class=3D"gmail-text-xl gmail-font-bold gmail-text-text-100 gmail-mt-1 g= mail--mb-0.5">Related Existing Ports:</h2>
<ul class=3D"gmail-[&:not(:last-child)_ul]:pb-1 gmail-[&:not(:last-= child)_ol]:pb-1 gmail-list-disc gmail-space-y-1.5 gmail-pl-7">
<li class=3D"gmail-whitespace-normal gmail-break-words">comms/SoapySDR (fra= mework)</li>
<li class=3D"gmail-whitespace-normal gmail-break-words">comms/SoapyRTLSDR, = comms/SoapyHackRF, comms/SoapyAirspy (similar backends)</li>
<li class=3D"gmail-whitespace-normal gmail-break-words">comms/rtl-sdr, comm= s/hackrf (hardware support)</li>
<li class=3D"gmail-whitespace-normal gmail-break-words">math/fftw3 (depende= ncy)</li>
</ul>
<p class=3D"gmail-whitespace-normal gmail-break-words">Thank you for your t= ime and consideration.</p>
<p class=3D"gmail-whitespace-normal gmail-break-words">Best regards,<span c= lass=3D"gmail_default" style=3D"font-size:small"></span></p></div><span cla= ss=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail= _signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">Larry Gadal= lah, NM7A/VE6VQ lgadallah AT gmail DOT com</div><div dir=3D"ltr">PGP Sig: 0= 247 9AD1 FFA8 2E35 0B5B=C2=A0 E387 F9B8 2875 FDFE DB69</div></div></div>
--000000000000445a2d063eefb549--
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to
news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2