Re: [Discuss-gnuradio] Submitting OOT Module Questions

[Ron Economos]

You can take a look at my last gr-dtv commit. It's very similar to what you need to do.

https://github.com/gnuradio/gnuradio/commit/b90c574e2fbf0443e1eea2ee06779c2a85f86def

Files to consider:

gr-dtv/grc/CMakeLists.txt

gr-dtv/grc/dtv_block_tree.xml

gr-dtv/lib/CMakeLists.txt

gr-dtv/swig/dtv_swig.i

gr-dtv/include/gnuradio/dtv/CMakelists.txt

Actually, I forgot to update that last file. Pull request imminent.

Ron

On 09/23/2015 01:55 PM, Richard Bell wrote:

Sorry if these are obvious questions, but this is very not obvious to me. As I understand it right now, it's not even a question of copy and pasting files over to gr-analog, because that would overwrite the code for all the other blocks, at least when it comes to swig. So let me outline what I need to do and see how close I am to understanding this:

1) I can copy and paste the source code, the qa code and example files over to corresponding gr-analog directories

2) I have to make changes to existing swig files in gr-analog, which amounts to copying the various lines from my OOT swig into the gr-analog swig

3) I don't know if I should be copying CMakeFile stuff or touching any of that by hand. I need guidance here.

Am I supposed to build this and confirm its merged correctly before I submit a pull request?

Rich

On Wed, Sep 23, 2015 at 12:06 PM, Tom Rondeau <address@hidden> wrote:

On Wed, Sep 23, 2015 at 2:38 PM, Richard Bell <address@hidden> wrote:

When merging my OOT module with the forked GNU Radio base, should I hand copy the *.xml, *.h, *_impl.h, *_impl.cc, qa_*.cc and qa_*.h in the appropriate gr-analog folder locations, or should I just dump my entire OOT module into the top level of the GNU Radio repo? I'm not familiar enough with CMake and how it does its thing to think this through on my own.

Rich

You need to copy your code into gr-analog and make sure that the cmake files and swig files are also updated accordingly.

Tom

 

On Wed, Sep 23, 2015 at 11:10 AM, Marcus D. Leech <address@hidden> wrote:

On 09/23/2015 02:07 PM, Dan CaJacob wrote:

I like keeping the algorithm logic in comments.  I can't count how many times I have optimized something, overwriting the original readable code, then come back in a few months to discover I have no idea how it works anymore.

Months?  Weeks for me :)

On Wed, Sep 23, 2015 at 1:54 PM Martin Braun <address@hidden> wrote:

On 23.09.2015 10:39, Richard Bell wrote:
> Hey everyone,
>
> I'm in the process of submitting my first OOT module for merge with GNU
> Radio base. It's a log gain AGC which converges much faster then the
> current AGCs when the input signal energy is low. I've read through the
> following link:
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
>
> 1) My first question relates to documentation. Up to now, I've added
> documentation into my XML files as <doc></doc> tags. To use Doxygen, am
> I correct to put them in the public *.h file? Is this the only place it
> should go, or should I add it to the XML as well? I've never been able
> to get my documentation to propagate through to the GRC block without
> putting it into the XML, is this a sign of a problem?

You should only need to put your docs in the Doxygen block.

> 2) If I understand the above link correctly, I should fork GNU Radio,
> create a new branch which I might call Log_AGC, add my code to that
> branch and then make a pull request. Am I misunderstanding anything?

That's the way to go. See also
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development

> 3) As far as code style goes, should I avoid using
>
> #define DEBUG
> #ifdef DEBUG
> std::cout << "Debug stuff" << "\n";
> #endif

Absolutely. Please use the logging interface. See also
http://gnuradio.org/doc/doxygen/page_logger.html
>
> statements to hide debug code? That is what I currently do but I know
> it's not prevalent in the source.
>
> 4) I currently have an Optimize option in the GRC block which picks
> between the way you would write the block if you just used standard C++
> statements (not optimized) and if you use Volk (optimized). Using
> control ports to compare the two, there is an improvement with volk. But
> I like that someone looking into the block can see how not to do it and
> then how to do it. Good for beginners jumping into GNU Radio.

That's noble, but for core GNU Radio stuff it's probably best if you
stick with the VOLK implementation.

M

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--

Very Respectfully,

Dan CaJacob

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio