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.cue...@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@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
