Thursday, March 19, 2026

Re:Self-proposed idea: BeiDou B1C Signal Simulator OOT Module

Subject: Re: [GSoC 2026] Self-proposed idea: BeiDou B1C Signal Simulator OOT Module

Hello Sir,

The constellation simulator direction makes much more sense. If the output can actually give a software receiver enough to compute a real PVT fix, that's something genuinely useful  for researchers, students,  anyone.

So here's how I'm thinking about the expanded scope now

- multi-constellation  , with Doppler shifts and time-of-flight delays that match what a receiver at a given location and time would actually see
- Generate proper navigation messages  so a receiver can extract ephemeris and compute a position fix
- Validate everything using GNSS-SDR as a software receiver  feed the generated I/Q straight in and check if it produces a valid PVT solution. No hardware needed.

One thing I'm unsure about: is it better to do BeiDou B1C really well and completely, or to cover B1C + GPS L1C + Galileo E1 at a slightly shallower level? Since all three share 1575.42 MHz I can see the appeal of multi-constellation.Would love your take on this.

I'll start working on a proper week-by-week draft and share it here soon for feedback.

Best,
Devanshi.

On Thu, Mar 19, 2026 at 12:50 AM Daniel Estévez <daniel@destevez.net> wrote:
Hi Devanshi,

Thanks for sharing this idea. Here is some quick feedback.

You don't say explicitly, but my understanding from what you wrote is
that your idea is to generate a single B1C signal with nominal chip rate
and no Doppler. This does not seem enough work even for a small (90
hour) project, specially if you are already strongly familiar with GNSS
signal generation and the B1C signal. Such kind of simulator is of
fairly limited use, since it only allows to test that a receiver is
capable of acquiring and tracking a single signal in these conditions.
It is more common to have constellation simulators, which are capable of
simulating signals from multiple satellites whose times of flight and
Dopplers are consistent with the signals that a receiver in a given
location would see. A constellation simulator, if well planned out,
might be reasonable for a GSoC project (probably more on the larger side
of the project size spectrum). Constellation simulators can be used to
obtain a PVT solution with a receiver, and test it in reasonably
realistic conditions.

You should detail in your proposal how you plan to test this. It is fine
that the tool itself generates baseband IQ and does not require any
hardware, but you will need to test somehow that the signals you are
generating are correct. Ideally you would use a hardware receiver and an
SDR to transmit your baseband IQ, but this requires you to already have
this hardware. If you don't have the required hardware, using a software
receiver is a good alternative, but you will need to identify such a
software receiver that allows you to check all you generate.

Another way in which you could increase the scope of your proposal and
make it more attractive is by including open service signals from other
constellations (GPS, Galileo, etc.), all of which have ICDs which are
publicly accessible.

Best,
Daniel.

On 18/03/2026 19:22, Devanshi B wrote:
> Hi GNU Radio community,
>
> I am Devanshi , a GSoC 2026 applicant interested in proposing a self-
> directed project.
>
> I have strong familiarity with GNSS signal generation concepts and the
> BeiDou B1C ICD specification, with hands-on experience .
>
> Proposed idea: A GNU Radio OOT module  tentatively gr-beidou 
> implementing a BeiDou B1C software signal simulator. The module would cover:
>
> - B1C PRN code generation (data and pilot components, per ICD)
> - BOC modulation
> - Basic CNAV-1 navigation message framing
> - Baseband I/Q output usable for receiver testing and simulation
>
> The implementation would be built entirely from the public BeiDou B1C
> ICD with no hardware dependency  making it useful for receiver testing,
> education, and research. I plan to model the module structure after gr-
> satellites, which sets a great precedent for clean, well-documented
> signal-level OOT modules.
>
> This fills a genuine gap  no open-source GNU Radio B1C signal generator
> currently exists.
>
> if any mentor would be interested in supervising this, or if there is a
> better framing that fits current GNU Radio priorities.
>
> Cyberspectrum is the best spectrum.

Re: Problem with 3.10.12.0

Hey Jim,
don't know how you've installed Pybind and your Python! As said, it looks like your update
of Python happened without the other libraries, and here, Pybind, getting rebuilt/updated
as well. I don't know your operating systems and installation methods, so it's impossible
for me to advise!

Best,
Marcus

On 2026-03-19 1:28 AM, Elmore Family wrote:
> What can I do to fix this issue?
>
> Jim
>
> -----Original Message----- From: Marcus Müller
> Sent: Monday, March 16, 2026 8:49 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: Problem with 3.10.12.0
>
> Hi Elmore,
>
> looks like you use Python to 3.13, but for some reason your pybind11 is linked against
> Python 3.11. Well, that might have different reasons, but it looks like an issue of
> inconsistent updates. It's not a GNU Radio bug!
>
> Best regards,
> Marcus
>
> On 2026-03-14 10:13 PM, Elmore Family wrote:
>> I recently upgraded to the subject version and am now missing some blocks.
>> I tried to rebuild one of my blocks and the following was the result:
>> cmake ../
>> CMake Deprecation Warning at CMakeLists.txt:12 (cmake_minimum_required):
>>    Compatibility with CMake < 3.10 will be removed from a future version of
>>    CMake.
>>    Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
>>    to tell CMake that the project requires at least <min> but has been updated
>>    to work with policies introduced by <max> or earlier.
>> -- The CXX compiler identification is GNU 14.2.0
>> -- The C compiler identification is GNU 14.2.0
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Check for working CXX compiler: /usr/bin/c++ - skipped
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working C compiler: /usr/bin/cc - skipped
>> -- Detecting C compile features
>> -- Detecting C compile features - done
>> -- Build type not specified: defaulting to release.
>> -- Using GMP.
>> CMake Warning (dev) at /usr/share/cmake-3.31/Modules/CMakeFindDependencyMacro.cmake:76
>> (find_package):
>>    Policy CMP0167 is not set: The FindBoost module is removed. Run "cmake
>>    --help-policy CMP0167" for policy details.  Use the cmake_policy command to
>>    set the policy and suppress this warning.
>> Call Stack (most recent call first):
>>    /usr/lib/aarch64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:28 (find_dependency)
>>    CMakeLists.txt:77 (find_package)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>> -- Found Boost: /usr/lib/aarch64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found
>> suitable version "1.83.0", minimum required is "1.83.0") found components: date_time
>> program_options system regex thread unit_test_framework
>> -- User set python executable /usr/bin/python3
>> CMake Warning (dev) at /usr/lib/aarch64-linux-gnu/cmake/gnuradio/GrPython.cmake:21
>> (find_package):
>>    Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
>>    are removed.  Run "cmake --help-policy CMP0148" for policy details. Use
>>    the cmake_policy command to set the policy and suppress this warning.
>> Call Stack (most recent call first):
>>    /usr/lib/aarch64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:37 (include)
>>    CMakeLists.txt:77 (find_package)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>> -- Found PythonInterp: /usr/bin/python3 (found version "3.13.5")
>> CMake Warning (dev) at /usr/lib/aarch64-linux-gnu/cmake/gnuradio/GrPython.cmake:27
>> (find_package):
>>    Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
>>    are removed.  Run "cmake --help-policy CMP0148" for policy details. Use
>>    the cmake_policy command to set the policy and suppress this warning.
>> Call Stack (most recent call first):
>>    /usr/lib/aarch64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:37 (include)
>>    CMakeLists.txt:77 (find_package)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>> -- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.11.so (Required is exact
>> version "3.13")
>> -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
>> -- Found pybind11: /usr/include (found version "2.13.6")
>> -- Using install prefix: /usr/local
>> -- Building for version: v1.0-compat-xxx-xunknown / 1.0.0git
>> -- No C++ unit tests... skipping
>> -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
>> -- PYTHON and GRC components are enabled
>> -- Python checking for pygccxml - found
>> -- Configuring done (10.5s)
>> CMake Error in python/bindings/CMakeLists.txt:
>>    Imported target "pybind11::module" includes non-existent path
>>      "/usr/include/python3.11"
>>    in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:
>>    * The path was deleted, renamed, or moved to another location.
>>    * An install or uninstall procedure did not complete successfully.
>>    * The installation package was faulty and references files it does not
>>    provide.
>> -- Generating done (0.2s)
>> CMake Generate step failed.  Build files cannot be regenerated correctly.
>> What is happening here?
>> Jim
>>
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-
>> email&utm_content=emailclient> Virus-free.www.avg.com <http://www.avg.com/email-
>> signature? utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
>

Wednesday, March 18, 2026

Re: Problem with 3.10.12.0

What can I do to fix this issue?

Jim

-----Original Message-----
From: Marcus Müller
Sent: Monday, March 16, 2026 8:49 AM
To: discuss-gnuradio@gnu.org
Subject: Re: Problem with 3.10.12.0

Hi Elmore,

looks like you use Python to 3.13, but for some reason your pybind11 is
linked against
Python 3.11. Well, that might have different reasons, but it looks like an
issue of
inconsistent updates. It's not a GNU Radio bug!

Best regards,
Marcus

On 2026-03-14 10:13 PM, Elmore Family wrote:
> I recently upgraded to the subject version and am now missing some blocks.
> I tried to rebuild one of my blocks and the following was the result:
> cmake ../
> CMake Deprecation Warning at CMakeLists.txt:12 (cmake_minimum_required):
> Compatibility with CMake < 3.10 will be removed from a future version
> of
> CMake.
> Update the VERSION argument <min> value. Or, use the <min>...<max>
> syntax
> to tell CMake that the project requires at least <min> but has been
> updated
> to work with policies introduced by <max> or earlier.
> -- The CXX compiler identification is GNU 14.2.0
> -- The C compiler identification is GNU 14.2.0
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Build type not specified: defaulting to release.
> -- Using GMP.
> CMake Warning (dev) at
> /usr/share/cmake-3.31/Modules/CMakeFindDependencyMacro.cmake:76
> (find_package):
> Policy CMP0167 is not set: The FindBoost module is removed. Run "cmake
> --help-policy CMP0167" for policy details. Use the cmake_policy
> command to
> set the policy and suppress this warning.
> Call Stack (most recent call first):
> /usr/lib/aarch64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:28
> (find_dependency)
> CMakeLists.txt:77 (find_package)
> This warning is for project developers. Use -Wno-dev to suppress it.
> -- Found Boost:
> /usr/lib/aarch64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found
> suitable version "1.83.0", minimum required is "1.83.0") found components:
> date_time program_options system regex thread unit_test_framework
> -- User set python executable /usr/bin/python3
> CMake Warning (dev) at
> /usr/lib/aarch64-linux-gnu/cmake/gnuradio/GrPython.cmake:21
> (find_package):
> Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs
> modules
> are removed. Run "cmake --help-policy CMP0148" for policy details.
> Use
> the cmake_policy command to set the policy and suppress this warning.
> Call Stack (most recent call first):
> /usr/lib/aarch64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:37
> (include)
> CMakeLists.txt:77 (find_package)
> This warning is for project developers. Use -Wno-dev to suppress it.
> -- Found PythonInterp: /usr/bin/python3 (found version "3.13.5")
> CMake Warning (dev) at
> /usr/lib/aarch64-linux-gnu/cmake/gnuradio/GrPython.cmake:27
> (find_package):
> Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs
> modules
> are removed. Run "cmake --help-policy CMP0148" for policy details.
> Use
> the cmake_policy command to set the policy and suppress this warning.
> Call Stack (most recent call first):
> /usr/lib/aarch64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:37
> (include)
> CMakeLists.txt:77 (find_package)
> This warning is for project developers. Use -Wno-dev to suppress it.
> -- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.11.so (Required
> is exact version "3.13")
> -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
> -- Found pybind11: /usr/include (found version "2.13.6")
> -- Using install prefix: /usr/local
> -- Building for version: v1.0-compat-xxx-xunknown / 1.0.0git
> -- No C++ unit tests... skipping
> -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
> -- PYTHON and GRC components are enabled
> -- Python checking for pygccxml - found
> -- Configuring done (10.5s)
> CMake Error in python/bindings/CMakeLists.txt:
> Imported target "pybind11::module" includes non-existent path
> "/usr/include/python3.11"
> in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
> * The path was deleted, renamed, or moved to another location.
> * An install or uninstall procedure did not complete successfully.
> * The installation package was faulty and references files it does not
> provide.
> -- Generating done (0.2s)
> CMake Generate step failed. Build files cannot be regenerated correctly.
> What is happening here?
> Jim
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-
> email&utm_content=emailclient> Virus-free.www.avg.com
> <http://www.avg.com/email-signature?
> utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>



--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

Hiring: SDR Engineer (Satellite Communications) – Remos Space

Hi all,

I would like to share that we are currently looking to hire an experienced SDR Engineer at Remos Space Systems AB.

Remos develops software-defined modems and ground segment solutions for satellite TT&C and data downlink. As part of our continued growth, we are expanding our engineering team to support ongoing and upcoming missions.

We are particularly interested in candidates with strong experience in:
• Software Defined Radios (SDR)
• Digital Signal Processing (DSP)
• Digital communications systems
• Time and phase synchronization

Familiarity with space communication standards such as CCSDS and DVB-S2X is highly desirable.

The role is based in northern Sweden and can be full-time or part-time. We are open to both onsite and remote arrangements. For remote candidates, occasional onsite visits will be required, and Remos will cover travel and accommodation costs.

If this sounds interesting to you, or if you know someone who might be a good fit, please feel free to reach out.

Regards,
Dr Moses Browne Mwakyanjala

Re: Self-proposed idea: BeiDou B1C Signal Simulator OOT Module

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEOn0gFAd3OQG8ow6EtFwrk3lBwykFAmm6+qoACgkQtFwrk3lB
wykZbQ/+LssxK6t4SzvJTjIVwolZLYo8+NEnJ4LFiFYANDr0p3ZMOF4ZYt/0AGOv
UxZfW1zlzy+If3Mw5PJfxrRGLwuMXMlVb5F9/rvC4bgd6oTUGtfG9JBWN90TP25P
iQLnBMz1XAxkRkEhSWDL3tgPq5zDO4GbHRXDxaldkQ5+E1VkMSuLjGOfaV7NSoRg
nEZQqz4ZmEs7uyM3o7GH/mVJL0+4VU2mb+MAGegd4sztHlO7oJhfB5CKS50oFzS6
UekO2S0mEqJ/7b47B8pfiT4axmXzvUzRBkPa8KAbkO05cPGmYcENf8a78c98p8/O
chQ0WPmwUxq/x3umwqCq7sjVraO4juzkJKlkoHZN1A1eMl/YlJC3nRMTZMs7aQlU
bQ71uHzknPaKw90VZhcK0qTR5KYqoKrHXwbsxbDXEq6NpI9u5HQZsGiox2cK2utV
vhdIRu6iLvHfOjfiV69R74odP02iTPwGKwGkarvTlZ+An+yOtnUFaV0vI0WGLGm7
S8nJe9z2lyB6bg+eh1CgkodMdPVc0p3QLIJBot9Hjbfgs/A3YVP6+uwCL8/vTflK
grtPMkk1rOT47wzUU7TlW7SuvtdaB1I3wXxnSlbrCACJugX4RkPx/XZPdcSj6/gv
xIi7+cuVXkOWBxLbklBoXPzAbjftvrZXU6GK34ZUXN16Y5dODDE=
=tAQD
-----END PGP SIGNATURE-----
Hi Devanshi,

Thanks for sharing this idea. Here is some quick feedback.

You don't say explicitly, but my understanding from what you wrote is
that your idea is to generate a single B1C signal with nominal chip rate
and no Doppler. This does not seem enough work even for a small (90
hour) project, specially if you are already strongly familiar with GNSS
signal generation and the B1C signal. Such kind of simulator is of
fairly limited use, since it only allows to test that a receiver is
capable of acquiring and tracking a single signal in these conditions.
It is more common to have constellation simulators, which are capable of
simulating signals from multiple satellites whose times of flight and
Dopplers are consistent with the signals that a receiver in a given
location would see. A constellation simulator, if well planned out,
might be reasonable for a GSoC project (probably more on the larger side
of the project size spectrum). Constellation simulators can be used to
obtain a PVT solution with a receiver, and test it in reasonably
realistic conditions.

You should detail in your proposal how you plan to test this. It is fine
that the tool itself generates baseband IQ and does not require any
hardware, but you will need to test somehow that the signals you are
generating are correct. Ideally you would use a hardware receiver and an
SDR to transmit your baseband IQ, but this requires you to already have
this hardware. If you don't have the required hardware, using a software
receiver is a good alternative, but you will need to identify such a
software receiver that allows you to check all you generate.

Another way in which you could increase the scope of your proposal and
make it more attractive is by including open service signals from other
constellations (GPS, Galileo, etc.), all of which have ICDs which are
publicly accessible.

Best,
Daniel.

On 18/03/2026 19:22, Devanshi B wrote:
> Hi GNU Radio community,
>
> I am Devanshi , a GSoC 2026 applicant interested in proposing a self-
> directed project.
>
> I have strong familiarity with GNSS signal generation concepts and the
> BeiDou B1C ICD specification, with hands-on experience .
>
> Proposed idea: A GNU Radio OOT module  tentatively gr-beidou
> implementing a BeiDou B1C software signal simulator. The module would cover:
>
> - B1C PRN code generation (data and pilot components, per ICD)
> - BOC modulation
> - Basic CNAV-1 navigation message framing
> - Baseband I/Q output usable for receiver testing and simulation
>
> The implementation would be built entirely from the public BeiDou B1C
> ICD with no hardware dependency  making it useful for receiver testing,
> education, and research. I plan to model the module structure after gr-
> satellites, which sets a great precedent for clean, well-documented
> signal-level OOT modules.
>
> This fills a genuine gap  no open-source GNU Radio B1C signal generator
> currently exists.
>
> if any mentor would be interested in supervising this, or if there is a
> better framing that fits current GNU Radio priorities.
>
> Cyberspectrum is the best spectrum.

Self-proposed idea: BeiDou B1C Signal Simulator OOT Module

Hi GNU Radio community,

I am Devanshi , a GSoC 2026 applicant interested in proposing a self-directed project.

I have strong familiarity with GNSS signal generation concepts and the BeiDou B1C ICD specification, with hands-on experience . 

Proposed idea: A GNU Radio OOT module  tentatively gr-beidou  implementing a BeiDou B1C software signal simulator. The module would cover:

- B1C PRN code generation (data and pilot components, per ICD)
- BOC modulation
- Basic CNAV-1 navigation message framing
- Baseband I/Q output usable for receiver testing and simulation

The implementation would be built entirely from the public BeiDou B1C ICD with no hardware dependency  making it useful for receiver testing, education, and research. I plan to model the module structure after gr-satellites, which sets a great precedent for clean, well-documented signal-level OOT modules.

This fills a genuine gap  no open-source GNU Radio B1C signal generator currently exists. 

if any mentor would be interested in supervising this, or if there is a better framing that fits current GNU Radio priorities.

Cyberspectrum is the best spectrum.

Re: [GSoC] GRC UI Improvements: Sub-flowgraphs and Mini-map Prototype – Request for Feedback

Hi Suryasaradhi,

welcome to the community!
Thanks for being part of the GSoC candidates!

I'll very likely not be your mentor, but I think it's great you're reaching out to discuss
your proposal:

On 2026-03-18 2:21 AM, B Suryasaradhi wrote:
> Both features are currently implemented as working prototypes in GTK and Implementation in
> QT is happening.

great! We mostly try to focus our development efforts on Qt these days.
> Context
>
> I am exploring these ideas in the context of contributing to GNU Radio, potentially as a
> GSoC project. Before proceeding further, I wanted to ensure alignment with the project's
> direction and design expectations.

great! this is the way to go about discussing GSoC ideas :)

> Questions
> Would these features be suitable for integration into GRC?

I'll defer to Håkon on that, who tries to keep GRC together and moving in a consistent
direction :)

Generally, they seem to be nice features.

> Are there existing efforts or design discussions related to sub-flowgraphs or
> navigation improvements that I should align with?

Sub-Flowgraphs: kind of! We used to have the ability to create hierarchical blocks fully
functional (I remember it having a few rough edges, though. Don't know its current state!)
You show the menu where you can create hierarchical blocks, so you're probably aware of
that functionality.
I think it would be a very good idea discuss in which ways the technical differences
between these two, creating a hier block or creating a subgraph, affect how people can use
them. I bet this will pretty much revolve around scope/visibility of objects! For example,
if you have a "Variable" in a GNU Radio flow graph and use a hier block in that flow
graph, the internals don't see (and interfere) with that.
That's a big plus for the hier block when it comes to "reusability", because all the
things you need to transport from the outside in need to be explicitly declared (as
"Parameters").
You might want to discuss how subgraph address that – as grumpy old bug-fixing dude, I'd
tend towards "make it very explicit to which variables the subgraph is sensitive; default
to 'none of them'!", but I think that's the extreme there, and usability indicates you
want something closer to "expose all external variables internally, but don't allow
objects from the inside to come out, as that would be confusing". But maybe it's
"everything is visible: inside to the outside, outside to the inside of a subgraph,
everyone needs to take care to look inside their subgraphs when a conflict appears".

As you can see, your proposed feature is interesting, and leads to a design discussion,
that I think should be part of what you need to do within or before GSoC.

> What would be the recommended next step:
> refining the prototype,
> adapting it to GRC's architecture,
> or opening a draft PR for discussion?
Can't really tell you how confident you feel about your code. Point 3), a draft PR, would
imply part 2) has kind of already been done. But: Also a big fan of talking about actual
code instead of code we can't see, so if you feel like you would someone review your code,
then by all means, just go for it!

> I have attached this is a demo video of subflowgraph and minimap. I would love to complete
> this as part of GSOC.Since this idea is not listed in the idea list, I am looking for
> mentors.I have adhered to maintain the code style mentioned in the contributors document
> of gnuradio. If someone wants to take a look at the code the link is: github link
> <https://github.com/thesunRider/gnuradio>

Then you should probably also start drafting a GSoC proposal! (In case you haven't,
please, read through, really from start to finish, of
https://wiki.gnuradio.org/index.php?title=GSoCStudentInfo )

Doesn't have to be polished (in fact, most of us would rather read bullet points than
overly polished, overly much text, at this stage), but list what you want to do, in which
weeks of GSoC.


Best regards,
Marcus