[Solved] Re: Unit testing of message passing blocks

[Malte Lenhart]

Hi Vasil,

thanks so much for your instant and helpful answer! That is exactly what
I looked for!

On 08.09.21 08:54, Vasil Velichkov wrote:
> Have a look at gr-zeromq's unit tests - [1], [2].
> Instead of tb.run() you can use tb.start(), tb.stop() and tb.wait()

So summarizing what has been missing for me:
- add a stop() method to the block
- use start(), stop() and wait() in the unit test instead of run()

I looked mainly in the gr-blocks folder because that is referenced
mostly in the documentation. I wrote a unit test for the message strobe
block, testing against the message debug block [1]. I thought a test in
the gr-blocks will improve the visibility of your testing approach. Plus
another block has a unit test then.
As stated in the PR, I was wondering if using the same test for the
message debug block would be beneficial (one more block w/ test) or
unnecessary (duplicated code, additional test time). I would be very
happy for short feedback on that.

Closing remark: start() and wait() don't seem to be documented in the
python unittest page [2], is this gnu radio specific? (the question is
rather, should it be documented somewhere and if yes where :-) )

Thanks so much and best regards

Malte


[1] https://github.com/gnuradio/gnuradio/pull/5053

[2] https://docs.python.org/3/library/unittest.html#unittest.TestResult.stop




OpenPGP_signature
Description: OpenPGP digital signature

Re: Sending a signal to a USRP N200

[Marcus D Leech]

I assume these are old systems?

Sent from my iPhone

> On Sep 8, 2021, at 1:19 PM, isaac mario tupac davila  
> wrote:
> 
> 
> Hi 
> 
> It seems the problem is the Rx daughterboard because I changed the USRP, used 
> the same flowgraph in GRC and it has worked.
> 
> Thanks for the help.
> Regards
> Isaac T.
> 
>> El lun, 6 sept 2021 a las 17:53, Marcus D. Leech () 
>> escribió:
>> On 2021-09-06 5:33 p.m., isaac mario tupac davila wrote:
>>> Hi
>>> 
>>> I've probed A:A, A:B, A:AB, A:BA and had the same behavior. Doesn't change.
>>> 
>>> regards
>>> Isaac T
>>> 
>>> 
>> This should make NO DIFFERENCE, but what version of Gnu Radio are you using? 
>>  
>> 
>> The fact that you're using WX GUI bits and pieces probably means something 
>> somewhat old.
>> 
>> The "modern" approach would be to use Qt GUI elements that do very similar 
>> things to what
>>   the (deprecated for quite some time) WX GUI bits and pieces do.
>> 
>> 
>>> 
>>> El lun, 6 sept 2021 a las 15:43, Marcus D. Leech 
>>> () escribió:
 On 2021-09-06 3:24 p.m., isaac mario tupac davila wrote:
> Hi.
> -- The daughterboard is the BasicRX Daughterboard.
> -- I put the address of  my USRP as 192.168.10.1
> **
> soporte@i28:~$ ping 192.168.10.1
> PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
> 64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.051 ms
> 64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.051 ms
> 64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=0.049 ms
> **
> soporte@28:~$ uhd_usrp_probe --args type=n200
 Try setting a subdev spec of:
 
 A:A
 
 
> Error: LookupError: KeyError: No devices found for ->
> Device Address:
> type: n200
> ***
> soporte@28:~$ uhd_find_devices
> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; 
> UHD_3.14.1.1-0-g7c0291ad
> --
> -- UHD Device 0
> --
> Device Address:
> serial: 3176CEA
> addr: 192.168.10.2
> name: 
> type: usrp2
> ***
> soporte@28:~$ uhd_usrp_probe
> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; 
> UHD_3.14.1.1-0-g7c0291ad
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> [WARNING] [USRP2] Unable to identify device - assuming USRP2/N-Series 
> device
> [WARNING] [UHD] Unable to set the thread priority. Performance may be 
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>   _
>  /
> |   Device: USRP2 / N-Series Device
> | _
> |/
> |   |   Mboard: N???
> |   |   mac-addr: 00:2c:00:00:00:24
> |   |   ip-addr: 0.0.0.0
> |   |   subnet: 0.0.0.0
> |   |   gateway: 255.255.255.255
> |   |   gpsdo: none
> |   |   serial: 3176CEA
> |   |   FW Version: 12.3
> |   |   FPGA Version: 10.0
> |   |   
> |   |   Time sources:  none, external, _external_, mimo
> |   |   Clock sources: internal, external, mimo
> |   |   Sensors: mimo_locked, ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |   
> |   |   |   Freq range: -50.000 to 50.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |   
> |   |   |   Freq range: -50.000 to 50.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: Basic RX (0x0001)
> |   |   |   Serial: 315A5DF
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: AB
> |   |   |   |   Name: BasicRX (AB)
> |   |   |   |   Antennas: 
> |   |   |   |   Sensors: 
> |   |   |   |   Freq range: -250.000 to 250.000 MHz
> |   |   |   |   Gain Elements: None
> |   |   |   |   Bandwidth range: 5.0 to 5.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
>>

Re: Sending a signal to a USRP N200

[isaac mario tupac davila]

Hi

It seems the problem is the Rx daughterboard because I changed the USRP,
used the same flowgraph in GRC and it has worked.

Thanks for the help.
Regards
Isaac T.

El lun, 6 sept 2021 a las 17:53, Marcus D. Leech ()
escribió:

> On 2021-09-06 5:33 p.m., isaac mario tupac davila wrote:
>
> Hi
>
> I've probed A:A, A:B, A:AB, A:BA and had the same behavior. Doesn't change.
>
> regards
> Isaac T
>
>
> This should make NO DIFFERENCE, but what version of Gnu Radio are you
> using?
>
> The fact that you're using WX GUI bits and pieces probably means something
> somewhat old.
>
> The "modern" approach would be to use Qt GUI elements that do very similar
> things to what
>   the (deprecated for quite some time) WX GUI bits and pieces do.
>
>
>
> El lun, 6 sept 2021 a las 15:43, Marcus D. Leech ()
> escribió:
>
>> On 2021-09-06 3:24 p.m., isaac mario tupac davila wrote:
>>
>> Hi.
>> -- The daughterboard is the BasicRX Daughterboard.
>> -- I put the address of  my USRP as 192.168.10.1
>>
>> **
>> soporte@i28:~$ ping 192.168.10.1
>> PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
>> 64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.051 ms
>> 64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.051 ms
>> 64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=0.049 ms
>>
>> **
>> soporte@28:~$ uhd_usrp_probe --args type=n200
>>
>> Try setting a subdev spec of:
>>
>> A:A
>>
>>
>> Error: LookupError: KeyError: No devices found for ->
>> Device Address:
>> type: n200
>>
>> ***
>> soporte@28:~$ uhd_find_devices
>> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501;
>> UHD_3.14.1.1-0-g7c0291ad
>> --
>> -- UHD Device 0
>> --
>> Device Address:
>> serial: 3176CEA
>> addr: 192.168.10.2
>> name:
>> type: usrp2
>>
>> ***
>> soporte@28:~$ uhd_usrp_probe
>> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501;
>> UHD_3.14.1.1-0-g7c0291ad
>> [INFO] [USRP2] Opening a USRP2/N-Series device...
>> [INFO] [USRP2] Current recv frame size: 1472 bytes
>> [INFO] [USRP2] Current send frame size: 1472 bytes
>> [WARNING] [USRP2] Unable to identify device - assuming USRP2/N-Series
>> device
>> [WARNING] [UHD] Unable to set the thread priority. Performance may be
>> negatively affected.
>> Please see the general application notes in the manual for instructions.
>> EnvironmentError: OSError: error in pthread_setschedparam
>>   _
>>  /
>> |   Device: USRP2 / N-Series Device
>> | _
>> |/
>> |   |   Mboard: N???
>> |   |   mac-addr: 00:2c:00:00:00:24
>> |   |   ip-addr: 0.0.0.0
>> |   |   subnet: 0.0.0.0
>> |   |   gateway: 255.255.255.255
>> |   |   gpsdo: none
>> |   |   serial: 3176CEA
>> |   |   FW Version: 12.3
>> |   |   FPGA Version: 10.0
>> |   |
>> |   |   Time sources:  none, external, _external_, mimo
>> |   |   Clock sources: internal, external, mimo
>> |   |   Sensors: mimo_locked, ref_locked
>> |   | _
>> |   |/
>> |   |   |   RX DSP: 0
>> |   |   |
>> |   |   |   Freq range: -50.000 to 50.000 MHz
>> |   | _
>> |   |/
>> |   |   |   RX DSP: 1
>> |   |   |
>> |   |   |   Freq range: -50.000 to 50.000 MHz
>> |   | _
>> |   |/
>> |   |   |   RX Dboard: A
>> |   |   |   ID: Basic RX (0x0001)
>> |   |   |   Serial: 315A5DF
>> |   |   | _
>> |   |   |/
>> |   |   |   |   RX Frontend: AB
>> |   |   |   |   Name: BasicRX (AB)
>> |   |   |   |   Antennas:
>> |   |   |   |   Sensors:
>> |   |   |   |   Freq range: -250.000 to 250.000 MHz
>> |   |   |   |   Gain Elements: None
>> |   |   |   |   Bandwidth range: 5.0 to 5.0 step 0.0 Hz
>> |   |   |   |   Connection Type: IQ
>> |   |   |   |   Uses LO offset: No
>> |   |   | _
>> |   |   |/
>> |   |   |   |   RX Frontend: BA
>> |   |   |   |   Name: BasicRX (BA)
>> |   |   |   |   Antennas:
>> |   |   |   |   Sensors:
>> |   |   |   |   Freq range: -250.000 to 250.000 MHz
>> |   |   |   |   Gain Elements: None
>> |   |   |   |   Bandwidth range: 5.0 to 5.0 step 0.0 Hz
>> |   |   |   |   Connection Type: QI
>> |   |   |   |   Uses LO offset: No
>> |   |   | __

Re: Regarding linking the libraries for undefined symbol error

[Johannes Demel]

Hi Arhum,

first off a few comments. You mention Ubuntu 16.04 which reached 
End-Of-Life (EOL) a few months back. Please don't use obsolete software. 
After all, it is a security risk. Besides, Ubuntu 16.04 exposed a series 
of bugs that are very specific to this distro. Thus, they are considered 
to be distro bugs. Since 16.04 is EOL and e.g. 20.04 does not expose 
these bugs (and in fact no other distro), it is unlikely that these 
issues will ever be fixed.


GNU Radio version 3.7.x is considered to be outdated at this point. It 
seems like you want to start a project. Newer GR versions offer a lot of 
packet data tools and blocks. I highly recommend to go with the latest 
GNU Radio 3.9 release.

https://wiki.gnuradio.org/index.php/UbuntuInstall
I assume these PDU utilities might help you to get even further:
https://github.com/sandialabs/gr-pdu_utils

Please don't send screenshots of terminal output. It is harder to read 
than necessary and more difficult to use. Just copy paste the terminal 
output.


Regarding your undefined symbol:
It might be the case that you ended up with an old VOLK version that 
does not include the `volk_32fc_index_max_32u` kernel. Thus, it lacks 
the `_manual` version as well.
If you consider installing a newer version of VOLK on Ubuntu 16.04, be 
aware that this will trigger a bug with this distros GCC version as well 
as some headers.


All of that brings me back to my first paragraph. Please start with a 
supported and recent toolchain that will definitely get you further.


Cheers
Johannes

On 06.09.21 12:35, Arhum Ahmad via GNU Radio, the Free & Open-Source 
Toolkit for Software Radio wrote:

Respected sir,
I am trying to transmit and receive packets in BPSK modulation for which 
I useGNU Radio Packetized 
transmissions> named gr-packetizer. 
It was installed through source in ubuntu version 16.04. Even though it 
successfully installed, when it runs it gives an attribute error (like: 
AttributeError: 'module' object has no attribute 'packet_encoder'). In 
order to debug it was tested using "ctest -V" (image attach) command in 
the build directory which failed 50%. Also the command `ldd -r lib/*.so` 
in build directory gives undefined symbols, both of them point error in 
"*volk_32fc_index_max_32u_manual*". This I was unable to solve and 
understand. Please help me with this. All related images are attached. 
I'll be highly obliged.


all related versions are:
GNU radio - 3.7.9
cmake - 3.5.1
GNU make - 4.1
python - 2.7.12
python3 - 3.5.2




--
*Thanks and Regards**
*
*Arhum Ahmad*
Ph.D. Scholar, Electrical Engineering Department, IIT Ropar

+91- 7974897279 | arhum.19eez0...@iitrpr.ac.in 



Lab No. 323, Communication Research Lab, J.C.Bose Building


*
/CONFIDENTIALITY NOTICE: The contents of this email message and any 
attachments are intended solely for the addressee(s) and may contain 
confidential and/or privileged information and may be legally protected 
from disclosure. If you are not the intended recipient of this message 
or their agent, or if this message has been addressed to you in error, 
please immediately alert the sender by reply email and then delete this 
message and any attachments. If you are not the intended recipient, you 
are hereby notified that any use, dissemination, copying, or storage of 
this message or its attachments is strictly prohibited./

*

Re: Unit testing of message passing blocks

[Vasil Velichkov]

Hi Malte,

Welcome to GNU Radio!

On 07/09/2021 23.42, Malte Lenhart wrote:
> This pattern does not seem to be uncommon, but I did not find a single
> instance with existing unit tests unfortunately..

Have a look at gr-zeromq's unit tests - [1], [2].

> Problem: when executing the python unit test, self.tb.run() blocks
> forever as the thread does not terminate. This only happens if the block
> is connected to another one in the flow graph.

Instead of tb.run() you can use tb.start(), tb.stop() and tb.wait()

[1] 
https://github.com/gnuradio/gnuradio/blob/4c6ae3a386ec19698a8c01144c4e8a52fc113404/gr-zeromq/python/zeromq/qa_zeromq_sub.py#L43-L49
[2] 
https://github.com/gnuradio/gnuradio/blob/4c6ae3a386ec19698a8c01144c4e8a52fc113404/gr-zeromq/python/zeromq/qa_zeromq_pull_msg_source.py#L35-L40

Regards,
Vasil