Re: GSoC 2026 Proposal Feedback Request -"Graphical interoperability between CyberEther and GNU Radio"

Amith Biju <[email protected]> Sun, 29 Mar 2026 19:22:50 +0530
Newsgroups gmane.comp.gnu.radio.general
Message-ID <CAFvtwg8SBX_nqhMn=hcrwDYOoXqzrt-7XDu7xQ7a-+9H742XmA@mail.gmail.com>
--000000000000789761064e2a0d48
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
>
> Yes, I=E2=80=99m aware of that.
>
> Since I picked this idea from the GSoC idea page, I mainly focused on
> designing CyberEther-powered visualization sinks for GNU Radio, so I didn=
=E2=80=99t
> go too deep into those limitations in the proposal.
>
> From what I understand, existing solutions like gr-fosphor are highly
> optimized but mainly focused on  waterfall and frequency domain  plots.
> With this approach, the goal is to support multiple types of
> visualization sinks using CyberEther.


> That said, I do recognize there are limitations in this approach, and I=
=E2=80=99m
> aiming to build a practical and extensible integration that makes
> CyberEther useful within the GNU Radio ecosystem.
>
> And I also saw recent GNU Radio Conference talks (2021=E2=80=932023) on
> CyberEther, where future plans to integrate CyberEther with Qt for use in
> GNU Radio were discussed, and with that consideration I made the proposal
> in this direction.
>
> Also, regarding the MSVC/clang-cl compatibility issue, I understand this
> could be a limitation for full integration into GNU Radio. For now, I was
> mainly considering a Linux based environment where CyberEther is supporte=
d
> and focusing on building a working pipeline first. Cross platform support
> can be explored later depending on feasibility .
>
> Would like to know if this approach is reasonable for the project scope.

--000000000000789761064e2a0d48
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><br>Yes, I=E2=80=99m aware of that=
.<br><br>Since I picked this idea from the GSoC idea page, I mainly focused=
 on designing CyberEther-powered visualization sinks for GNU Radio, so I di=
dn=E2=80=99t go too deep into those limitations in the proposal.<br><br>Fro=
m what I understand, existing solutions like gr-fosphor are highly optimize=
d but mainly focused on=C2=A0 waterfall and frequency domain=C2=A0 plots. W=
ith this approach, the goal is to support multiple types of visualization=
=C2=A0sinks using CyberEther.</blockquote><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><br>That said, I do recognize there are limitations in thi=
s approach, and I=E2=80=99m aiming to build a practical and extensible inte=
gration that makes CyberEther useful within the GNU Radio ecosystem.<br><br=
>And I also saw recent GNU Radio Conference talks (2021=E2=80=932023) on Cy=
berEther, where future plans to integrate CyberEther with Qt for use in GNU=
 Radio were discussed, and with that consideration I made the proposal in t=
his direction.<br><br>Also, regarding the MSVC/clang-cl compatibility issue=
, I understand this could be a limitation for full integration into GNU Rad=
io. For now, I was mainly considering a Linux based environment where Cyber=
Ether is supported and focusing on building a working pipeline first. Cross=
 platform support can be explored later depending on feasibility .<br><br>W=
ould like to know if this approach is reasonable for the project scope.
</blockquote></div></div>

--000000000000789761064e2a0d48--