[USRP-users] Issues/suggestions for latest rfnocmodtool

Michael Wentz mchlwntz at gmail.com
Thu Jul 13 11:45:56 EDT 2017


Hi Nicolas,

Thanks for the feedback. Interesting since I had a few blocks with
underscores in the name and had just removed the underscore from the XML
that UHD uses.

Regarding the QA tests, I tried porting some of the code I was using before
and am mostly getting 'timeout on chan 0' when using vector source/sink to
send test vectors through. In the past I had some success with this, not
only when using GR but with other tests I wrote using only UHD. From my
prospective it would definitely be nice to repeat the type of tests I do in
RTL simulation with hardware in the loop, i.e. doing a loopback through the
FPGA with signals generated from software.

-Michael

On Thu, Jul 13, 2017 at 7:18 AM, Nicolas Cuervo <nicolas.cuervo at ettus.com>
wrote:

> Hello Michael,
>
> It seems that 'import sys' is missing from the top of
>> gr-ettus/python/utils/rfnocmodtool
>>
> Yeah, this was known actually, and the fix is there. It just needs to be
> pushed public. We are sorry you had to face this.
>
>
>> After changing that, I ran into this problem:
>>
>>     rfnocmodtool newmod test
>>     Could not find rfnoc-newmod source dir
>>
>> It turns out that gr-ettus/modtool_newmod.py is not set up for people
>> that do not use PYBOMBS but do have a custom install prefix. All I had to
>> do was copy that over to PYBOMBS_PREFIX and then newmod worked. I would
>> have thought my install prefix would have been set up in any necessary
>> files during cmake?
>>
> The path hint that the modtool uses is PyBombs (as you correctly point
> out) and the common /usr/local/ and such. When the path is custom,
> rfnocmodtool requires the path of the newmod to be given with the
> "--srcdir" option.
>
>     $ rfnocmodtool help newmod
>        General options:
>    .
>    .
>    .
>       newmod:
>       New out-of-tree module options
>
>       --srcdir SRCDIR       Source directory for the module template.
>
> Maybe a more descriptive "Could not find message" would be required, where
> it is said that the --srcdir option might be required to be explicitly
> given.
>
>
>> I was also wondering if there are reasons why underscores are not allowed
>> in block names
>>
> The underscores are not allowed in the names because we use them to
> designate block identifiers. This means, for example, that under the hood
> we refer to the "RFNoC: Radio" on channel 0 as 0/Radio_0 and so on. Given
> this, some naming that has underscores in it will lead to code mismatches
> and conflicts that could only be solved by code refactoring. This is the
> reason why we just added this constraint as a requirement.
>
>
> , and why the QA templates were removed (I liked using these to do tests
>> with hardware in the loop)?
>>
> We sincerely thought that no one was using this, as having hardware in the
> loop for, lets say, a python QA code, was not a trivial use case. If you
> are willing to elaborate on exactly how you are achieving this, we would
> not be against bringing the QA templates back.
>
> Regards,
> - Nicolas
>
>
>
>
>> -Michael
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170713/b5754e81/attachment-0002.html>


More information about the USRP-users mailing list