Re: [Discuss-gnuradio] Hopping Frequency Synchronization algorithm used

On Sat, Jun 8, 2013 at 11:28 AM, Jay Prakash <address@hidden> wrote:

PU is basically a primary user.

I want to build frequency hopping transmitter receiver for PUs.

The primary users will be hopping in a given no of bands and secondary users will opportunistically sense empty band and communicate with each other.

Now the problem is how do I synchronize receiver and transmitter while frequency hopping?

You wrote fssh_engine.py. But I did not understood much through it as I am not so well familiar with pmt,blob and gr-extras.

So I was interested in knowing the algorithm so that I can write codes for the hopping synchronization.

I am more interested in using python scripts and Gnu Radio support to design the synchronized hopping.

Suppose the transmitter has a list of hopping frequencies and so does receiver.Now primary starts transmitting and receiver has to sense which channel primary is transmitting and insure locking.

There is certain lag associated with USRP and this should be taken in to account for synchronization.

Jay Prakash
Senior Undergraduate

Electronics Engineering
IIT (BHU)
VARANASI

+91-9559475258
http://about.me/jay.prakash/

http://www.linkedin.com/profile/view?id=91120191&trk=hb_tab_pro_top

On Sat, Jun 8, 2013 at 11:14 PM, John Malsbury <address@hidden> wrote:

Jay,

Thanks for checking out pre-cog. I'm not sure what "algorithm" you'd call it, or if calling it an "algorithm" might be giving the implementation more credit than it deserves, but here is the basic MO of the FHSS blocks:

All I/O is to/from the FHSS_hier implementations is done with message passing - currently of gr-extras variety. Someday, with Johnathan Corgan's help this may get converted to the new message passing API in gnuradio.

The TX blocks read the rx sample stream from the USRP, pull off stream tags, and count samples to maintain an awareness of the USRP time. It tracks this time, and when a target time elapses, the block issues a tuning command via XML_RPT, and a timed burst via tagged sample packets in a stream. After each time, we set the next time we want to transmit. In reality, the act of issuing the tune command and sending a burst happens some time (1-5 ms) before the actual burst occurs. The frequencies are provided to the block as a parameter - comma delimited text.

On the receive side, the FHSS simply tunes the USRP to the first frequency of the frequency list. It waits here until it receives a valid packet - then it uses a similar process to (2) to start hopping in lock step.

This was a basic demo of how to use stream tags and message passing to integrate control functions in a GRC flowgraph. There's a lot of potential improvements - its slow, it could be converted to C++, etc. Once you've got the basics up and running, I do invite contributions to pre-cog or gnuradio.

I've attached files for an FHSS transceiver, but I'd start off with the simplex examples in the repo.

-John

On Sat, Jun 8, 2013 at 8:42 AM, Jay Prakash <address@hidden> wrote:

I am working on hopping frequency data transfer for PU (RX-TX).

I need to have both rx tx aware of which channel to communicate with in each hop.

I read about FHSS implementation in PRECOG.

Which algorithm is being used there to synchronize them?

Can I get a brief code walk through?

Jay Prakash

On Fri, Jun 7, 2013 at 9:30 PM, <address@hidden> wrote:
Send Discuss-gnuradio mailing list submissions to
address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
address@hidden

You can reach the person managing the list at
address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."

Today's Topics:

1. GNU Radio Companion isn't aware of custom pythonpath(s)
(Arturo Rinaldi)
2. Re: GNU Radio Companion isn't aware of custom pythonpath(s)
(Josh Blum)
3. Tun/Tap Problem while Running tunnel.py while wireshark
recognizes (Jay Prakash)
4. Re: GNU Radio Companion isn't aware of custom pythonpath(s)
(Marcus D. Leech)
5. Re: Ucla Zigbee compiling issues on MacOs X and Ubuntu
12.04.2 LTS (Arturo Rinaldi)
6. make test errors (Botany Dave)
7. Re: BBN 802.11b RSSI output (Dan Cocuzzo)
8. 3.6.5 test fail (Nemanja Savic)
9. Re: Add another device to work with gnuradio (dolphyvn)
10. Re: GNU Radio Companion isn't aware of custom pythonpath(s)
(Gregory Warnes)
11. Re: Add another device to work with gnuradio
(Monahan-Mitchell, Tim)
12. Re: GNU Radio Companion isn't aware of custom pythonpath(s)
(Arturo Rinaldi)
13. Re: GNU Radio Companion isn't aware of custom pythonpath(s)
(Martin Braun (CEL))
14. Re: 3.6.5 test fail (Johnathan Corgan)
15. Re: GNU Radio Companion isn't aware of custom pythonpath(s)
(Marcus D. Leech)

----------------------------------------------------------------------

Message: 1
Date: Thu, 06 Jun 2013 20:54:09 +0200
From: Arturo Rinaldi <address@hidden>
To: GNU Radio mailing list <address@hidden>
Subject: [Discuss-gnuradio] GNU Radio Companion isn't aware of custom
pythonpath(s)
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"

I bumped into a strange issue in the past few days. When i launch GRC by
the desktop link generated, the program itself isn't aware of my custom
pythonpath set in the .bashrc settings file. I tried to modify the
desktop link also by checking the option to *launch the program in a
terminal* and putting into the blank space :

/export PYTHONPATH=$PYTHONPATH:<my-custom-path> \ gnuradio-companion/

but without any results. I have never experienced this issue with the
past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio
3.6.4.1. The only way it works is by making a script and launch it from
my desktop. No issues if i launch GRC from shell, after all the
pythonpath is embedded in the launched shell.

thanks in advance for helping me.

Kind Regards,

Arturo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130606/54065d41/attachment.html>

------------------------------

Message: 2
Date: Thu, 06 Jun 2013 15:08:23 -0400
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] GNU Radio Companion isn't aware of
custom pythonpath(s)
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

On 06/06/2013 02:54 PM, Arturo Rinaldi wrote:
> I bumped into a strange issue in the past few days. When i launch GRC by
> the desktop link generated, the program itself isn't aware of my custom
> pythonpath set in the .bashrc settings file. I tried to modify the
> desktop link also by checking the option to *launch the program in a
> terminal* and putting into the blank space :
>
> /export PYTHONPATH=$PYTHONPATH:<my-custom-path> \ gnuradio-companion/
>
> but without any results. I have never experienced this issue with the
> past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio
> 3.6.4.1. The only way it works is by making a script and launch it from
> my desktop. No issues if i launch GRC from shell, after all the
> pythonpath is embedded in the launched shell.
>
> thanks in advance for helping me.

I can confirm that this is an issue. There may need to be a helper
gnuradio-companion script that sets the env vars and then calls the
actual python script. The gnuradio-grc.desktop would call this script
instead. Not sure of a better way to do that.

-josh

>
> Kind Regards,
>
> Arturo
>
>
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

------------------------------

Message: 3
Date: Fri, 7 Jun 2013 00:52:51 +0530
From: Jay Prakash <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Tun/Tap Problem while Running tunnel.py
while wireshark recognizes
Message-ID:
<CADVr-4wMwgYsg4=+address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

We are working on establishing a tunnel for MAC protocol design using
tunnel.py given as example in GNU Radio but are unable to receive ping
reply from the other node.

We created tun/tap interface using ./tunnel.py -f 990M and ipconfig
192.168.200.1 on Machine A connected to N210 series of USRP.
and ./tunnel.py -f 990M and ifconfig 192.168.200.2 on machine B.

1. Now on pinging machine B from A we can see ping packets being sent to B
by A using wireshark, but there is no reply on node A.

2. We went into details and saw there were ARQ requests from B repetitively.
I manually added the mac address to update the table.
Now ARQ request ceased to exist but still there were no replies on A.

3. Since we knew the Packaging details of ICMP we read the packets being
received by B and found the exact source address of A from the frame. It
means message have been successfully decoded by the destination and it
knows whom to reply for the ping but still I don't find any reception
confirmation on source side.

What may be the possible problems?USRP antenna gain?Packets collision?

In short we are unable to use tunnely.py and are seeking for possible
causes.

Jay Prakash
Senior Undergraduate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130607/a28f97e4/attachment.html>

------------------------------

Message: 4
Date: Thu, 06 Jun 2013 17:14:18 -0400
From: "Marcus D. Leech" <address@hidden>
To: address@hidden, "address@hidden"
<address@hidden>
Subject: Re: [Discuss-gnuradio] GNU Radio Companion isn't aware of
custom pythonpath(s)
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

>
> On 06/06/2013 02:54 PM, Arturo Rinaldi wrote:
>> I bumped into a strange issue in the past few days. When i launch GRC by
>> the desktop link generated, the program itself isn't aware of my custom
>> pythonpath set in the .bashrc settings file. I tried to modify the
>> desktop link also by checking the option to *launch the program in a
>> terminal* and putting into the blank space :
>>
>> /export PYTHONPATH=$PYTHONPATH:<my-custom-path> \ gnuradio-companion/
>>
>> but without any results. I have never experienced this issue with the
>> past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio
>> 3.6.4.1. The only way it works is by making a script and launch it from
>> my desktop. No issues if i launch GRC from shell, after all the
>> pythonpath is embedded in the launched shell.
>>
>> thanks in advance for helping me.
> I can confirm that this is an issue. There may need to be a helper
> gnuradio-companion script that sets the env vars and then calls the
> actual python script. The gnuradio-grc.desktop would call this script
> instead. Not sure of a better way to do that.
>
> -josh
>
>
>
In Ubuntu, terminals aren't automatically "login" terminals, and so
don't run your .bashrc, although for terminals at least, you can configure
them to pretend to be "login" terminals, and thus run your .bashrc.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

------------------------------

Message: 5
Date: Fri, 07 Jun 2013 01:04:11 +0200
From: Arturo Rinaldi <address@hidden>
To: Bastian Bloessl <address@hidden>
Cc: GNU Radio mailing list <address@hidden>
Subject: Re: [Discuss-gnuradio] Ucla Zigbee compiling issues on MacOs
X and Ubuntu 12.04.2 LTS
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

Il 06/06/13 07:23, Bastian Bloessl ha scritto:
> Hello Arturo,
>
> On 06/06/2013 01:55 AM, Arturo Rinaldi wrote:
>> I have recently bumped into some issues when building the ucla_zigbee
>> platform both on macos and ubuntu 12.04.2. I'll shortly sum up my two
>> setups :
>
> I think the UCLA blocks were not updated to work with GNU Radio 3.6.4.
> I made some 802.15.4 blocks based on the UCLA Phy. Maybe you want to
> give them a try.
>
> https://github.com/bastibl/gr-ieee802-15-4
>
> The last commits port the blocks to v3.7 API. If you want to use 3.6.4
> you should go back some commits
>
> git checkout v3.6
>
> Best,
> Bastian
>
>
>
Hi Sebastian,

I've just successfully built the zigbee platform with gnuradio-3.6.4.1
on Kubuntu 13.04. I already found your zigbee port some time ago but I
need the whole complete distro. I have done another tweak in the
*Makefile.common* file I attached last night, to fine tuning the python
installation directory of the files with :

/grpythondir = /usr/lib/python2.7/dist-packages/gnuradio/

and all went smoothly. Tomorrow i'll test my 12.04 machine hoping that
this is the reason why i couldn't install zigbee on it. MacOS X issues
still persist.

Regards,

Arturo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130607/e91caae1/attachment.html>

------------------------------

Message: 6
Date: Thu, 6 Jun 2013 20:52:28 -0700 (PDT)
From: Botany Dave <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] make test errors
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

I'm new to this, and I'm sure it will show...

I am trying to install and run Gnu Radio in an Ubuntu 12.10 environment. I
followed the instructions at
http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installation-Overview
and am getting errors on four modules when I run make test. They are:

86 - qa_fir_filter
91 - qa_freq__xlating_fir_filter
150 - qa_constellation_receiver
169 - qa_codec2_vocoder

Here is the output of ctest -V -R qa for each of those modules. I'd really
appreciate any guidance on how to resolve these failures.

86: Test command: /bin/sh
"/home/dave/gnuradio/build/gr-filter/python/qa_fir_filter_test.sh"
86: Test timeout computed to be: 9.99988e+06
86: .........FF
86: ======================================================================
86: FAIL: test_fir_filter_scc_001 (__main__.test_filter)
86: ----------------------------------------------------------------------
86: Traceback (most recent call last):
86: File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line
262, in test_fir_filter_scc_001
86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
86: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
74, in assertComplexTuplesAlmostEqual
86: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
86: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
47, in assertComplexAlmostEqual
86: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
))
86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places
86:
86: ======================================================================
86: FAIL: test_fir_filter_scc_002 (__main__.test_filter)
86: ----------------------------------------------------------------------
86: Traceback (most recent call last):
86: Using Volk machine: avx_32_mmx
86: File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line
281, in test_fir_filter_scc_002
86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
86: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
74, in assertComplexTuplesAlmostEqual
86: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
86: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
47, in assertComplexAlmostEqual
86: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
))
86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places
86:
86: ----------------------------------------------------------------------
86: Ran 11 tests in 0.035s
86:
86: FAILED (failures=2)
1/1 Test #86: qa_fir_filter ....................***Failed 0.30 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 0.31 sec

The following tests FAILED:
86 - qa_fir_filter (Failed)
Errors while running CTest

91: Test command: /bin/sh
"/home/dave/gnuradio/build/gr-filter/python/qa_freq_xlating_fir_filter_test.sh"
91: Test timeout computed to be: 9.99988e+06
91: ........FFFF
91: ======================================================================
91: FAIL: test_fir_filter_scc_001 (__main__.test_freq_xlating_filter)
91: ----------------------------------------------------------------------
91: Traceback (most recent call last):
91: File
"/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
412, in test_fir_filter_scc_001
91: self.assertComplexTuplesAlmostEqual(expected_data,
result_data[-20:], 5)
91: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
74, in assertComplexTuplesAlmostEqual
91: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
91: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
47, in assertComplexAlmostEqual
91: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
))
91: AssertionError: (-0.00775564694777+0.0437113791704j) != (nan+nanj)
within 5 places
91:
91: ======================================================================
91: Using Volk machine: avx_32_mmx
91: FAIL: test_fir_filter_scc_002 (__main__.test_freq_xlating_filter)
91: ----------------------------------------------------------------------
91: Traceback (most recent call last):
91: File
"/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
442, in test_fir_filter_scc_002
91: self.assertComplexTuplesAlmostEqual(expected_data,
result_data[-20:], 5)
91: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
74, in assertComplexTuplesAlmostEqual
91: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
91: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
47, in assertComplexAlmostEqual
91: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
))
91: AssertionError: (-0.0080680437386-0.00158522999845j) != (nan+nanj)
within 5 places
91:
91: ======================================================================
91: FAIL: test_fir_filter_scf_001 (__main__.test_freq_xlating_filter)
91: ----------------------------------------------------------------------
91: Traceback (most recent call last):
91: File
"/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
352, in test_fir_filter_scf_001
91: self.assertComplexTuplesAlmostEqual(expected_data,
result_data[-20:], 5)
91: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
74, in assertComplexTuplesAlmostEqual
91: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
91: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
47, in assertComplexAlmostEqual
91: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
))
91: AssertionError: (-0.0330070219934+0.101965591311j) != (nan+nanj) within
5 places
91:
91: ======================================================================
91: FAIL: test_fir_filter_scf_002 (__main__.test_freq_xlating_filter)
91: ----------------------------------------------------------------------
91: Traceback (most recent call last):
91: File
"/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
382, in test_fir_filter_scf_002
91: self.assertComplexTuplesAlmostEqual(expected_data,
result_data[-20:], 5)
91: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
74, in assertComplexTuplesAlmostEqual
91: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
91: File
"/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
47, in assertComplexAlmostEqual
91: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
))
91: AssertionError: (0.00824625696987-1.50158575707e-05j) != (nan+nanj)
within 5 places
91:
91: ----------------------------------------------------------------------
91: Ran 12 tests in 0.045s
91:
91: FAILED (failures=4)
1/1 Test #91: qa_freq_xlating_fir_filter .......***Failed 0.32 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 0.34 sec

The following tests FAILED:
91 - qa_freq_xlating_fir_filter (Failed)
Errors while running CTest

150: Test command: /bin/sh
"/home/dave/gnuradio/build/gr-digital/python/qa_constellation_receiver_test.sh"
150: Test timeout computed to be: 9.99988e+06
150: Segmentation fault (core dumped)
1/1 Test #150: qa_constellation_receiver ........***Failed 13.64 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 13.66 sec

The following tests FAILED:
150 - qa_constellation_receiver (Failed)
Errors while running CTest

169: Test command: /bin/sh
"/home/dave/gnuradio/build/gr-vocoder/python/qa_codec2_vocoder_test.sh"
169: Test timeout computed to be: 9.99988e+06
169: F
169: ======================================================================
169: FAIL: test001_module_load (__main__.test_codec2_vocoder)
169: ----------------------------------------------------------------------
169: Traceback (most recent call last):
169: File "/home/dave/gnuradio/gr-vocoder/python/qa_codec2_vocoder.py",
line 56, in test001_module_load
169: self.assertEqual(expected_data, actual_result)
169: AssertionError: Tuples differ: (0, 0, 0, 3, 2, 0, 1, 5, 6, 7,... !=
(0L, 0L, 0L, 3L, 2L, 0L, 1L, 5...
169:
169: First differing element 112:
169: 24
169: 25
169:
169: Diff is 3978 characters long. Set self.maxDiff to None to see it.
169:
169: ----------------------------------------------------------------------
169: Ran 1 test in 0.503s
169:
169: FAILED (failures=1)
1/1 Test #169: qa_codec2_vocoder ................***Failed 0.86 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 0.87 sec

The following tests FAILED:
169 - qa_codec2_vocoder (Failed)
Errors while running CTest

I've rerun apt-get on for the following, and all report back as being the
most current release:
python-dev
python-wxgtk2.8
python-numpy
python-cheetah
python-lxml
python-qt4
python-qwt5-qt4

Any help you can offer would be very much appreciated.
libqt4-opengl-dev libqwt5-qt4-dev libfontconfig1-dev libxrender-dev

--
View this message in context: http://gnuradio.4.n7.nabble.com/make-test-errors-tp41841.html
Sent from the GnuRadio mailing list archive at Nabble.com.

------------------------------

Message: 7
Date: Fri, 7 Jun 2013 07:16:28 +0000 (UTC)
From: Dan Cocuzzo <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] BBN 802.11b RSSI output
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

Guess not.

------------------------------

Message: 8
Date: Fri, 7 Jun 2013 10:24:55 +0200
From: Nemanja Savic <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] 3.6.5 test fail
Message-ID:
<CAFD_UOdg=address@hidden>
Content-Type: text/plain; charset="utf-8"

Hi all,

today I have a problem to build 3.6.5 which I downloaded yesterday.
When I do make test 2 tests fail:

99% tests passed, 2 tests failed out of 240
>
> The following tests FAILED:
> 105 - qa_file_metadata (Failed)
> 132 - qa_udp_source_sink (Failed)
> Errors while running CTest
>
> As for the qa_file metadata, the report is following:

105/240 Testing qa_file_metadata
> Test command: /bin/sh
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/python/qa_file_metadata_test.sh
> Test timeout computed to be: 9.99988e+06
> EE
> ======================================================================
> ERROR: test_001 (__main__.test_file_metadata)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/home/savi_ne/tools/gnuradio-3.6.5/gr-blocks/python/qa_file_metadata.py",
> line 81, in test_001
> self.assertGreater(len(extra_str), 0)
> AttributeError: 'test_file_metadata' object has no attribute
> 'assertGreater'
>
> ======================================================================
> ERROR: test_002 (__main__.test_file_metadata)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/home/savi_ne/tools/gnuradio-3.6.5/gr-blocks/python/qa_file_metadata.py",
> line 160, in test_002
> self.assertGreater(len(extra_str), 0)
> AttributeError: 'test_file_metadata' object has no attribute
> 'assertGreater'
>
> ----------------------------------------------------------------------
> Ran 2 tests in 0.008s
>
> FAILED (errors=2)
> <pmt_swig.swig_int_ptr; proxy of <Swig Object of type
> 'boost::intrusive_ptr< pmt::pmt_base > *' at 0x4033db0> >
> <pmt_swig.swig_int_ptr; proxy of <Swig Object of type
> 'boost::intrusive_ptr< pmt::pmt_base > *' at 0x41af660> >
> -- Process completed
> ***Failed
> 106/240 Testing qa_probe_signal
> Test command: /bin/sh
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/python/qa_probe_signal_test.sh
> Test timeout computed to be: 9.99988e+06
> ..
>

It looks like my test module is missing something.

The second failure is caused by udp_source_sink, and here is the report:

132/240 Testing qa_udp_source_sink
> Test command: /bin/sh
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/python/qa_udp_source_sink_test.sh
> Test timeout computed to be: 9.99988e+06
> *** glibc detected *** /usr/bin/python2.6: double free or corruption
> (out): 0x00007f6708000930 ***
> ======= Backtrace: =========
> /lib64/libc.so.6[0x3283c760e6]
> /lib64/libc.so.6[0x3283c78c13]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/lib/libgnuradio-blocks-3.6.5.so.0.0.0(+0x158254)[0x7f671f4c1254]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/lib/libgnuradio-blocks-3.6.5.so.0.0.0(+0x127fc9)[0x7f671f490fc9]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/lib/libgnuradio-blocks-3.6.5.so.0.0.0(+0x121819)[0x7f671f48a819]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/lib/libgnuradio-blocks-3.6.5.so.0.0.0(+0x153a2c)[0x7f671f4bca2c]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/lib/libgnuradio-blocks-3.6.5.so.0.0.0(+0x153b29)[0x7f671f4bcb29]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gnuradio-core/src/lib/libgnuradio-core-3.6.5.so.0.0.0(+0xaf1b9)[0x7f672817c1b9]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gnuradio-core/src/lib/libgnuradio-core-3.6.5.so.0.0.0(_ZN12gr_flowgraphD1Ev+0x78)[0x7f6728184298]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gnuradio-core/src/lib/libgnuradio-core-3.6.5.so.0.0.0(+0xbcba2)[0x7f6728189ba2]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gnuradio-core/src/lib/libgnuradio-core-3.6.5.so.0.0.0(_ZN21gr_hier_block2_detailD1Ev+0xa7)[0x7f67281a07c7]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gnuradio-core/src/lib/libgnuradio-core-3.6.5.so.0.0.0(_ZN14gr_hier_block2D1Ev+0x2b)[0x7f672819ea6b]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gnuradio-core/src/lib/libgnuradio-core-3.6.5.so.0.0.0(_ZN12gr_top_blockD0Ev+0x9)[0x7f67281c0999]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gnuradio-core/src/lib/swig/_gnuradio_core_runtime.so(+0x64642)[0x7f67285c7642]
> /usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x3297843c63]
>
> /usr/lib64/libpython2.6.so.1.0(PyObject_CallFunctionObjArgs+0xc8)[0x3297843f38]
>
> /home/savi_ne/tools/gnuradio-3.6.5/build/gnuradio-core/src/lib/swig/_gnuradio_core_runtime.so(+0x1d145)[0x7f6728580145]
> /usr/lib64/libpython2.6.so.1.0[0x3297879e4b]
> /usr/lib64/libpython2.6.so.1.0[0x329789a75c]
> /usr/lib64/libpython2.6.so.1.0[0x3297879e4b]
> /usr/lib64/libpython2.6.so.1.0[0x329789a75c]
> /usr/lib64/libpython2.6.so.1.0[0x3297878287]
> /usr/lib64/libpython2.6.so.1.0(PyDict_SetItem+0xa7)[0x329787acf7]
> /usr/lib64/libpython2.6.so.1.0(PyObject_GenericSetAttr+0x11c)[0x329787da6c]
> /usr/lib64/libpython2.6.so.1.0(PyObject_SetAttr+0x87)[0x329787df37]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x1709)[0x32978d1ea9]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x32978d6b8f]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x32978d7657]
> /usr/lib64/libpython2.6.so.1.0[0x329786adad]
> /usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x3297843c63]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x32978d4470]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x32978d7657]
> /usr/lib64/libpython2.6.so.1.0[0x329786acb0]
> /usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x3297843c63]
> /usr/lib64/libpython2.6.so.1.0[0x32978566af]
> /usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x3297843c63]
> /usr/lib64/libpython2.6.so.1.0[0x3297895a54]
> /usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x3297843c63]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x47d4)[0x32978d4f74]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x32978d7657]
> /usr/lib64/libpython2.6.so.1.0[0x329786adad]
> /usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x3297843c63]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3cd0)[0x32978d4470]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x32978d7657]
> /usr/lib64/libpython2.6.so.1.0[0x329786acb0]
> /usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x3297843c63]
> /usr/lib64/libpython2.6.so.1.0[0x32978566af]
> /usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x3297843c63]
> /usr/lib64/libpython2.6.so.1.0[0x3297895a54]
> /usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x53)[0x3297843c63]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x47d4)[0x32978d4f74]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x63ef)[0x32978d6b8f]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x32978d7657]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5304)[0x32978d5aa4]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x927)[0x32978d7657]
> /usr/lib64/libpython2.6.so.1.0(PyEval_EvalCode+0x32)[0x32978d7732]
> /usr/lib64/libpython2.6.so.1.0[0x32978f1bac]
> /usr/lib64/libpython2.6.so.1.0(PyRun_FileExFlags+0x90)[0x32978f1c80]
> /usr/lib64/libpython2.6.so.1.0(PyRun_SimpleFileExFlags+0xdc)[0x32978f316c]
> /usr/lib64/libpython2.6.so.1.0(Py_Main+0xb62)[0x32978ff8a2]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3283c1ecdd]
> /usr/bin/python2.6[0x400649]
> ======= Memory map: ========
> 00400000-00401000 r-xp 00000000 08:01 267196
> /usr/bin/python2.6
> 00600000-00602000 rw-p 00000000 08:01 267196
> /usr/bin/python2.6
> 02315000-03984000 rw-p 00000000 00:00 0
> [heap]
> 3283800000-3283820000 r-xp 00000000 08:01 1581795
> /lib64/ld-2.12.so
> 3283a1f000-3283a20000 r--p 0001f000 08:01 1581795
> /lib64/ld-2.12.so
> 3283a20000-3283a21000 rw-p 00020000 08:01 1581795
> /lib64/ld-2.12.so
> 3283a21000-3283a22000 rw-p 00000000 00:00 0
> 3283c00000-3283d8a000 r-xp 00000000 08:01 1581805
> /lib64/libc-2.12.so
> 3283d8a000-3283f89000 ---p 0018a000 08:01 1581805
> /lib64/libc-2.12.so
> 3283f89000-3283f8d000 r--p 00189000 08:01 1581805
> /lib64/libc-2.12.so
> 3283f8d000-3283f8e000 rw-p 0018d000 08:01 1581805
> /lib64/libc-2.12.so
> 3283f8e000-3283f93000 rw-p 00000000 00:00 0
> 3284000000-3284017000 r-xp 00000000 08:01 1581815
> /lib64/libpthread-2.12.so
> 3284017000-3284217000 ---p 00017000 08:01 1581815
> /lib64/libpthread-2.12.so
> 3284217000-3284218000 r--p 00017000 08:01 1581815
> /lib64/libpthread-2.12.so
> 3284218000-3284219000 rw-p 00018000 08:01 1581815
> /lib64/libpthread-2.12.so
> 3284219000-328421d000 rw-p 00000000 00:00 0
> 3284400000-3284402000 r-xp 00000000 08:01 1582700
> /lib64/libdl-2.12.so
> 3284402000-3284602000 ---p 00002000 08:01 1582700
> /lib64/libdl-2.12.so
> 3284602000-3284603000 r--p 00002000 08:01 1582700
> /lib64/libdl-2.12.so
> 3284603000-3284604000 rw-p 00003000 08:01 1582700
> /lib64/libdl-2.12.so
> 3284800000-3284883000 r-xp 00000000 08:01 1581812
> /lib64/libm-2.12.so
> 3284883000-3284a82000 ---p 00083000 08:01 1581812
> /lib64/libm-2.12.so
> 3284a82000-3284a83000 r--p 00082000 08:01 1581812
> /lib64/libm-2.12.so
> 3284a83000-3284a84000 rw-p 00083000 08:01 1581812
> /lib64/libm-2.12.so
> 3284c00000-3284c15000 r-xp 00000000 08:01 1582699
> /lib64/libz.so.1.2.3
> 3284c15000-3284e14000 ---p 00015000 08:01 1582699
> /lib64/libz.so.1.2.3
> 3284e14000-3284e15000 r--p 00014000 08:01 1582699
> /lib64/libz.so.1.2.3
> 3284e15000-3284e16000 rw-p 00015000 08:01 1582699
> /lib64/libz.so.1.2.3
> 3285000000-3285007000 r-xp 00000000 08:01 1588066
> /lib64/librt-2.12.so
> 3285007000-3285206000 ---p 00007000 08:01 1588066
> /lib64/librt-2.12.so
> 3285206000-3285207000 r--p 00006000 08:01 1588066
> /lib64/librt-2.12.so
> 3285207000-3285208000 rw-p 00007000 08:01 1588066
> /lib64/librt-2.12.so
> 3285e00000-3285eef000 r-xp 00000000 08:01 264874
> /usr/lib64/libfftw3f.so.3.2.3
> 3285eef000-32860ef000 ---p 000ef000 08:01 264874
> /usr/lib64/libfftw3f.so.3.2.3
> 32860ef000-32860f6000 rw-p 000ef000 08:01 264874
> /usr/lib64/libfftw3f.so.3.2.3
> 3288400000-32884f0000 r-xp 00000000 08:01 266821
> /usr/lib64/libgfortran.so.3.0.0
> 32884f0000-32886ef000 ---p 000f0000 08:01 266821
> /usr/lib64/libgfortran.so.3.0.0
> 32886ef000-32886f1000 rw-p 000ef000 08:01 266821
> /usr/lib64/libgfortran.so.3.0.0
> 32886f1000-32886f2000 rw-p 00000000 00:00 0
> 3289400000-328941f000 r-xp 00000000 08:01 658890
> /usr/lib64/atlas/libf77blas.so.3.0
> 328941f000-328961e000 ---p 0001f000 08:01 658890
> /usr/lib64/atlas/libf77blas.so.3.0
> 328961e000-328961f000 rw-p 0001e000 08:01 658890
> /usr/lib64/atlas/libf77blas.so.3.0
> 328a400000-328a416000 r-xp 00000000 08:01 1582707
> /lib64/libgcc_s-4.4.7-20120601.so.1
> 328a416000-328a615000 ---p 00016000 08:01 1582707
> /lib64/libgcc_s-4.4.7-20120601.so.1
> 328a615000-328a616000 rw-p 00015000 08:01 1582707
> /lib64/libgcc_s-4.4.7-20120601.so.1
> 328a800000-328a8e8000 r-xp 00000000 08:01 267327
> /usr/lib64/libstdc++.so.6.0.13
> 328a8e8000-328aae8000 ---p 000e8000 08:01 267327
> /usr/lib64/libstdc++.so.6.0.13
> 328aae8000-328aaef000 r--p 000e8000 08:01 267327
> /usr/lib64/libstdc++.so.6.0.13
> 328aaef000-328aaf1000 rw-p 000ef000 08:01 267327
> /usr/lib64/libstdc++.so.6.0.13
> 328aaf1000-328ab06000 rw-p 00000000 00:00 0
> 328b400000-328b403000 r-xp 00000000 08:01 1588052
> /lib64/libcom_err.so.2.1
> 328b403000-328b602000 ---p 00003000 08:01 1588052
> /lib64/libcom_err.so.2.1
> 328b602000-328b603000 r--p 00002000 08:01 1588052
> /lib64/libcom_err.so.2.1
> 328b603000-328b604000 rw-p 00003000 08:01 1588052
> /lib64/libcom_err.so.2.1
> 328bc00000-328bc02000 r-xp 00000000 08:01 1582724
> /lib64/libkeyutils.so.1.3
> 328bc02000-328be01000 ---p 00002000 08:01 1582724
> /lib64/libkeyutils.so.1.3
> 328be01000-328be02000 r--p 00001000 08:01 1582724
> /lib64/libkeyutils.so.1.3
> 328be02000-328be03000 rw-p 00002000 08:01 1582724
> /lib64/libkeyutils.so.1.3
> 328d600000-328da53000 r-xp 00000000 08:01 656455
> /usr/lib64/atlas/libatlas.so.3.0
> 328da53000-328dc52000 ---p 00453000 08:01 656455
> /usr/lib64/atlas/libatlas.so.3.0
> 328dc52000-328dc5c000 rw-p 00452000 08:01 656455
> /usr/lib64/atlas/libatlas.so.3.0
> 328e200000-328e711000 r-xp 00000000 08:01 656443
> /usr/lib64/atlas/liblapack.so.3.0
> 328e711000-328e911000 ---p 00511000 08:01 656443
> /usr/lib64/atlas/liblapack.so.3.0
> 328e911000-328e914000 rw-p 00511000 08:01 656443
> /usr/lib64/atlas/liblapack.so.3.0
> 328e914000-328ea22000 rw-p 00000000 00:00 0
> 328f000000-328f020000 r-xp 00000000 08:01 656456
> /usr/lib64/atlas/libcblas.so.3.0
> 328f020000-328f21f000 ---p 00020000 08:01 656456
> /usr/lib64/atlas/libcblas.so.3.0
> 328f21f000-328f220000 rw-p 0001f000 08:01 656456
> /usr/lib64/atlas/libcblas.so.3.0
> 3294a00000-3294a02000 r-xp 00000000 08:01 1582709
> /lib64/libutil-2.12.so
> 3294a02000-3294c01000 ---p 00002000 08:01 1582709
> /lib64/libutil-2.12.so
> 3294c01000-3294c02000 r--p 00001000 08:01 1582709
> /lib64/libutil-2.12.so
> 3294c02000-3294c03000 rw-p 00002000 08:01 1582709
> /lib64/libutil-2.12.so
> 3297800000-329795d000 r-xp 00000000 08:01 309696
> /usr/lib64/libpython2.6.so.1.0
> 329795d000-3297b5c000 ---p 0015d000 08:01 309696
> /usr/lib64/libpython2.6.so.1.0
> 3297b5c000-3297b98000 rw-p 0015c000 08:01 309696
> /usr/lib64/libpython2.6.so.1.0
> 3297b98000-3297ba6000 rw-p 00000000 00:00 0
> 356e000000-356e174000 r-xp 00000000 08:01 289478
> /usr/lib64/libcrypto.so.1.0.0
> 356e174000-356e373000 ---p 00174000 08:01 289478
> /usr/lib64/libcrypto.so.1.0.0
> 356e373000-356e38c000 r--p 00173000 08:01 289478
> /usr/lib64/libcrypto.so.1.0.0
> 356e38c000-356e396000 rw-p 0018c000 08:01 289478
> /usr/lib64/libcrypto.so.1.0.0
> 356e396000-356e39a000 rw-p 00000000 00:00 0
> 3a1b800000-3a1b849000 r-xp 00000000 08:01 290449
> /usr/lib64/libboost_program_options-mt.so.5
> 3a1b849000-3a1ba49000 ---p 00049000 08:01 290449
> /usr/lib64/libboost_program_options-mt.so.5
> 3a1ba49000-3a1ba4d000 rw-p 00049000 08:01 290449
> /usr/lib64/libboost_program_options-mt.so.5
> 3a1e400000-3a1e403000 r-xp 00000000 08:01 292580
> /usr/lib64/libboost_system-mt.so.5
> 3a1e403000-3a1e602000 ---p 00003000 08:01 292580
> /usr/lib64/libboost_system-mt.so.5
> 3a1e602000-3a1e603000 rw-p 00002000 08:01 292580
> /usr/lib64/libboost_system-mt.so.5
> 3a20000000-3a20014000 r-xp 00000000 08:01 317579
> /usr/lib64/libboost_filesystem-mt.so.5
> 3a20014000-3a20214000 ---p 00014000 08:01 317579
> /usr/lib64/libboost_filesystem-mt.so.5
> 3a20214000-3a20215000 rw-p 00014000 08:01 317579
> /usr/lib64/libboost_filesystem-mt.so.5
> 3fdee00000-3fdee1d000 r-xp 00000000 08:01 1611794
> /lib64/libselinux.so.1
> 3fdee1d000-3fdf01c000 ---p 0001d000 08:01 1611794
> /lib64/libselinux.so.1
> 3fdf01c000-3fdf01d000 r--p 0001c000 08:01 1611794
> /lib64/libselinux.so.1
> 3fdf01d000-3fdf01e000 rw-p 0001d000 08:01 1611794
> /lib64/libselinux.so.1
> 3fdf01e000-3fdf01f000 rw-p 00000000 00:00 0
> 3fdf600000-3fdf60a000 r-xp 00000000 08:01 1611795
> /lib64/libkrb5support.so.0.1
> 3fdf60a000-3fdf809000 ---p 0000a000 08:01 1611795
> /lib64/libkrb5support.so.0.1
> 3fdf809000-3fdf80a000 r--p 00009000 08:01 1611795
> /lib64/libkrb5support.so.0.1
> 3fdf80a000-3fdf80b000 rw-p 0000a000 08:01 1611795
> /lib64/libkrb5support.so.0.1
> 3fdfa00000-3fdfadb000 r-xp 00000000 08:01 1611797
> /lib64/libkrb5.so.3.3
> 3fdfadb000-3fdfcda000 ---p 000db000 08:01 1611797
> /lib64/libkrb5.so.3.3
> 3fdfcda000-3fdfce4000 r--p 000da000 08:01 1611797
> /lib64/libkrb5.so.3.3
> 3fdfce4000-3fdfce6000 rw-p 000e4000 08:01 1611797
> /lib64/libkrb5.so.3.3
> 3fdfe00000-3fdfe29000 r-xp 00000000 08:01 1611796
> /lib64/libk5crypto.so.3.1
> 3fdfe29000-3fe0029000 ---p 00029000 08:01 1611796
> /lib64/libk5crypto.so.3.1
> 3fe0029000-3fe002a000 r--p 00029000 08:01 1611796
> /lib64/libk5crypto.so.3.1
> 3fe002a000-3fe002b000 rw-p 0002a000 08:01 1611796
> /lib64/libk5crypto.so.3.1
> 3fe002b000-3fe002c000 rw-p 00000000 00:00 0
> 3fe0600000-3fe0641000 r-xp 00000000 08:01 1611798
> /lib64/libgssapi_krb5.so.2.2
> 3fe0641000-3fe0841000 ---p 00041000 08:01 1611798
> /lib64/libgssapi_krb5.so.2.2
> 3fe0841000-3fe0842000 r--p 00041000 08:01 1611798
> /lib64/libgssapi_krb5.so.2.2
> 3fe0842000-3fe0844000 rw-p 00042000 08:01 1611798
> /lib64/libgssapi_krb5.so.2.2
> 3fe0e00000-3fe0e55000 r-xp 00000000 08:01 306925
> /usr/lib64/libssl.so.1.0.0
> 3fe0e55000-3fe1055000 ---p 00055000 08:01 306925
> /usr/lib64/libssl.so.1.0.0
> 3fe1055000-3fe1058000 r--p 00055000 08:01 306925
> /usr/lib64/libssl.so.1.0.0
> 3fe1058000-3fe105d000 rw-p 00058000 08:01 306925
> /usr/lib64/libssl.so.1.0.0
> 7f6700000000-7f6700021000 rw-p 00000000 00:00 0
> 7f6700021000-7f6704000000 ---p 00000000 00:00 0
> 7f6704000000-7f6704021000 rw-p 00000000 00:00 0
> 7f6704021000-7f6708000000 ---p 00000000 00:00 0
> 7f6708000000-7f6708021000 rw-p 00000000 00:00 0
> 7f6708021000-7f670c000000 ---p 00000000 00:00 0
> 7f670c000000-7f670c021000 rw-p 00000000 00:00 0
> 7f670c021000-7f6710000000 ---p 00000000 00:00 0
> 7f6710000000-7f6710021000 rw-p 00000000 00:00 0
> 7f6710021000-7f6714000000 ---p 00000000 00:00 0
> 7f67161fd000-7f67161fe000 ---p 00000000 00:00 0
> 7f67161fe000-7f6716bfe000 rw-p 00000000 00:00 0
> 7f6718000000-7f6718021000 rw-p 00000000 00:00 0
> 7f6718021000-7f671c000000 ---p 00000000 00:00 0
> 7f671c64c000-7f671c64d000 ---p 00000000 00:00 0
> 7f671c64d000-7f671d04d000 rw-p 00000000 00:00 0
> 7f671da4e000-7f671da4f000 ---p 00000000 00:00 0
> 7f671da4f000-7f671e44f000 rw-p 00000000 00:00 0
> 7f671e44f000-7f671e45b000 r-xp 00000000 08:01 1605043
> /lib64/libnss_files-2.12.so
> 7f671e45b000-7f671e65b000 ---p 0000c000 08:01 1605043
> /lib64/libnss_files-2.12.so
> 7f671e65b000-7f671e65c000 r--p 0000c000 08:01 1605043
> /lib64/libnss_files-2.12.so
> 7f671e65c000-7f671e65d000 rw-p 0000d000 08:01 1605043
> /lib64/libnss_files-2.12.so
> 7f671e65d000-7f671ea3f000 r-xp 00000000 08:01 1731518
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/swig/_blocks_swig2.so
> 7f671ea3f000-7f671ec3f000 ---p 003e2000 08:01 1731518
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/swig/_blocks_swig2.so
> 7f671ec3f000-7f671ec63000 rw-p 003e2000 08:01 1731518
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/swig/_blocks_swig2.so
> 7f671ec63000-7f671f13d000 r-xp 00000000 08:01 1731197
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/swig/_blocks_swig1.so
> 7f671f13d000-7f671f33c000 ---p 004da000 08:01 1731197
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/swig/_blocks_swig1.so
> 7f671f33c000-7f671f368000 rw-p 004d9000 08:01 1731197
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/swig/_blocks_swig1.so
> 7f671f368000-7f671f369000 rw-p 00000000 00:00 0
> 7f671f369000-7f671f524000 r-xp 00000000 08:01 1730547
> /home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/lib/libgnuradio-blocks-3.6.5.so.0.0.0/home/savi_ne/tools/gnuradio-3.6.5/build/gr-blocks/python/qa_udp_source_sink_test.sh:
> line 7: 22420 Aborted (core dumped) /usr/bin/python2.6 -B
> /home/savi_ne/tools/gnuradio-3.6.5/gr-blocks/python/qa_udp_source_sink.py
> -- Process completed
> ***Failed
>

I am also pretty sure that yesterday when I run make test for the first
time it was only one error caused by metadata..., and then I run ctest -V
and the second error appeared.
I am using RHEL 5, and since now everything was just fine.

Best regards and thank you,

--
Nemanja Savi?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130607/12e61d5a/attachment.html>

------------------------------

Message: 9
Date: Fri, 7 Jun 2013 01:40:38 -0700 (PDT)
From: dolphyvn <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Add another device to work with
gnuradio
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

Hi anyone can help?
I know this maybe a stupid question but you see as Im newbie.

--
View this message in context: http://gnuradio.4.n7.nabble.com/Add-another-device-to-work-with-gnuradio-tp41791p41844.html
Sent from the GnuRadio mailing list archive at Nabble.com.

------------------------------

Message: 10
Date: Fri, 7 Jun 2013 10:23:20 -0400
From: Gregory Warnes <address@hidden>
To: "Marcus D. Leech" <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] GNU Radio Companion isn't aware of
custom pythonpath(s)
Message-ID:
<CAKorm_tR1i_+Z-RdSZcL2-vB=address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

Perhaps something to add to the [grc] section of ~/.gnuradio/config.conf?

-Greg

On Thu, Jun 6, 2013 at 5:14 PM, Marcus D. Leech <address@hidden> wrote:
>>
>> On 06/06/2013 02:54 PM, Arturo Rinaldi wrote:
>>>
>>> I bumped into a strange issue in the past few days. When i launch GRC by
>>> the desktop link generated, the program itself isn't aware of my custom
>>> pythonpath set in the .bashrc settings file. I tried to modify the
>>> desktop link also by checking the option to *launch the program in a
>>> terminal* and putting into the blank space :
>>>
>>> /export PYTHONPATH=$PYTHONPATH:<my-custom-path> \ gnuradio-companion/
>>>
>>> but without any results. I have never experienced this issue with the
>>> past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio
>>> 3.6.4.1. The only way it works is by making a script and launch it from
>>> my desktop. No issues if i launch GRC from shell, after all the
>>> pythonpath is embedded in the launched shell.
>>>
>>> thanks in advance for helping me.
>>
>> I can confirm that this is an issue. There may need to be a helper
>> gnuradio-companion script that sets the env vars and then calls the
>> actual python script. The gnuradio-grc.desktop would call this script
>> instead. Not sure of a better way to do that.
>>
>> -josh
>>
>>
>>
> In Ubuntu, terminals aren't automatically "login" terminals, and so don't
> run your .bashrc, although for terminals at least, you can configure
> them to pretend to be "login" terminals, and thus run your .bashrc.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--
"Whereas true religion and good morals are the only solid foundations
of public liberty and happiness . . . it is hereby earnestly
recommended to the several States to take the most effectual measures
for the encouragement thereof." Continental Congress, 1778

------------------------------

Message: 11
Date: Fri, 7 Jun 2013 14:31:19 +0000
From: "Monahan-Mitchell, Tim" <address@hidden>
To: dolphyvn <address@hidden>, "address@hidden"
<address@hidden>
Subject: Re: [Discuss-gnuradio] Add another device to work with
gnuradio
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="us-ascii"

> Hi anyone can help?
> I know this maybe a stupid question but you see as Im newbie.
The only stupid questions are the ones that are not asked :)

Read the GR Wiki page on adding an out-of-tree module.

If your device is a receiver, you will want to write a Source Block. If it transmits, then write a Sink block. Or both if it does both.

You'll need to plan on how your device is going to talk to Linux. Does it already have drivers? Or do you need to write those? That part you can develop & test using Linux, outside of GR.

Tim

------------------------------

Message: 12
Date: Fri, 7 Jun 2013 16:38:35 +0200
From: Arturo Rinaldi <address@hidden>
To: Gregory Warnes <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] GNU Radio Companion isn't aware of
custom pythonpath(s)
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

i was thinking about it but i can't find the right argument to pass to the
config file. I looked up on the internet and there's no proper way to do in
a simple thing as :

[path]
mypath=path1:path2

so i decided to make my own script

*!# /bin/bash
*
*
export PYTHONPATH=$PYTHONPATH:<my-**custom-path> \

gnuradio-companion*

and link it to the .desktop file in my app menu in KDE. Gnuradio
documentation lacks this information, so i really don't know where to
search for.

Regards

2013/6/7 Gregory Warnes <address@hidden>

> Perhaps something to add to the [grc] section of ~/.gnuradio/config.conf?
>
> -Greg
>
> On Thu, Jun 6, 2013 at 5:14 PM, Marcus D. Leech <address@hidden> wrote:
> >>
> >> On 06/06/2013 02:54 PM, Arturo Rinaldi wrote:
> >>>
> >>> I bumped into a strange issue in the past few days. When i launch GRC
> by
> >>> the desktop link generated, the program itself isn't aware of my custom
> >>> pythonpath set in the .bashrc settings file. I tried to modify the
> >>> desktop link also by checking the option to *launch the program in a
> >>> terminal* and putting into the blank space :
> >>>
> >>> /export PYTHONPATH=$PYTHONPATH:<my-custom-path> \ gnuradio-companion/
> >>>
> >>> but without any results. I have never experienced this issue with the
> >>> past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio
> >>> 3.6.4.1. The only way it works is by making a script and launch it from
> >>> my desktop. No issues if i launch GRC from shell, after all the
> >>> pythonpath is embedded in the launched shell.
> >>>
> >>> thanks in advance for helping me.
> >>
> >> I can confirm that this is an issue. There may need to be a helper
> >> gnuradio-companion script that sets the env vars and then calls the
> >> actual python script. The gnuradio-grc.desktop would call this script
> >> instead. Not sure of a better way to do that.
> >>
> >> -josh
> >>
> >>
> >>
> > In Ubuntu, terminals aren't automatically "login" terminals, and so don't
> > run your .bashrc, although for terminals at least, you can configure
> > them to pretend to be "login" terminals, and thus run your .bashrc.
> >
> >
> > --
> > Marcus Leech
> > Principal Investigator
> > Shirleys Bay Radio Astronomy Consortium
> > http://www.sbrac.org
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> --
> "Whereas true religion and good morals are the only solid foundations
> of public liberty and happiness . . . it is hereby earnestly
> recommended to the several States to take the most effectual measures
> for the encouragement thereof." Continental Congress, 1778
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130607/40fb1312/attachment.html>

------------------------------

Message: 13
Date: Fri, 7 Jun 2013 16:48:34 +0200
From: "Martin Braun (CEL)" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] GNU Radio Companion isn't aware of
custom pythonpath(s)
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"

On Fri, Jun 07, 2013 at 04:38:35PM +0200, Arturo Rinaldi wrote:
> i was thinking about it but i can't find the right argument to pass to the
> config file. I looked up on the internet and there's no proper way to do in a
> simple thing as :
>
>
> [path]
>
> mypath=path1:path2

Actually, that works.

E.g.:

[grc]
global_blocks_path = path1:path2
local_blocks_path =

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstra?e 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130607/24f2678d/attachment.pgp>

------------------------------

Message: 14
Date: Fri, 7 Jun 2013 10:51:46 -0400
From: Johnathan Corgan <address@hidden>
To: Nemanja Savic <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] 3.6.5 test fail
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

On Fri, Jun 7, 2013 at 4:24 AM, Nemanja Savic <address@hidden> wrote:

> 105 - qa_file_metadata (Failed)
>

This issue has been fixed on the repository 'maint' branch and will
eventually make it into release 3.6.5.1. It had already been corrected on
the current 'master' branch for 3.7.

--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130607/00c1a382/attachment.html>

------------------------------

Message: 15
Date: Fri, 07 Jun 2013 11:14:23 -0400
From: "Marcus D. Leech" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] GNU Radio Companion isn't aware of
custom pythonpath(s)
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

> On Fri, Jun 07, 2013 at 04:38:35PM +0200, Arturo Rinaldi wrote:
>> i was thinking about it but i can't find the right argument to pass to the
>> config file. I looked up on the internet and there's no proper way to do in a
>> simple thing as :
>>
>>
>> [path]
>>
>> mypath=path1:path2
> Actually, that works.
>
> E.g.:
>
> [grc]
> global_blocks_path = path1:path2
> local_blocks_path =
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
That's the path for the .xml blocks, not the corresponding PYTHON.

You just need to make sure that your PYTHONPATH variable is exported
into the process running GRC. Its children with then see that PYTHONPATH.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130607/9315a5c4/attachment.html>

------------------------------

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

End of Discuss-gnuradio Digest, Vol 127, Issue 10
*************************************************

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

From:	John Malsbury
Subject:	Re: [Discuss-gnuradio] Hopping Frequency Synchronization algorithm used in PRE-COG
Date:	Sat, 8 Jun 2013 11:44:55 -0700