[Discuss-gnuradio] binary data transmission

[anju babu]

I'm doing my M.Tech project in gnuradio and i'm using gnuradio companion.My
project is underwater communication system.in that i have to transmit the
data from a file source after frequency modulation .My file source output
type is byte.I have to transmit my data in binary format for eg.if  1 is
written on file it should be transmitted as 0001.similarly for
characters its ascii's binary have to be transmitted.kindly suggest me any
method for the same.
-- 
*ANJU BABU*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem running uhd_fft.py

[Andrew Davis]

Well that should be fast enough, could you give us the exact command you
used to start uhd_fft.py

Also what do you mean by "installing ubuntu 10.04 using windows installer",
are you running linux in a VM?

On Sun, Feb 5, 2012 at 3:11 AM, davood ahmady  wrote:

> Hello Andrew
> thanks for your reply
> My desktop pc has 4 Giga Ram, Daul processor 2.8 Giaga, and installing
> ubuntu 10.04 using windows installer. you mean that it is not enough?
> thank you,
> Davood
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ldconfig problem

[osama mohamed]

hi all,

i am installing uhd on the e100 but i have 2 problems
after i finished the installation i ran ldconfig and this is what i got
1-ldconfig: /usr/lib/libstdc++.so.6.0.14-gdb.py is not an ELF file - it has the 
wrong magic bytes at the start.
2-can't find the file /etc/ld.so.conf

any help would be appreciated

thanks ,

osama
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Serious performance regression in Gnu Radio recent

[Marcus D. Leech]

I have an application, SIDSuite, that I've been running on my hardware 
here for about 18 months continuously, with reasonable performance
  (the UI isn't totally-snappy, but acceptable).  Some time recently, 
with an upgrade of Gnu Radio, the performance became utterly
  unacceptable--the UI became unusable, and updates to the FFT and 
Waterfall sinks became very "chunky".  I haven't changed the

  app in months and months.

So, I started taking my Gnu Radio back further and further in time, 
until I was back to "normal".  I had to regress my GIT tree back to:


commit 2ed887b69a3b15840830998c4e6157176d427f60
Author: Josh Blum 
Date:   Sat Dec 31 13:06:01 2011 -0800

In order to get decent performance again.

I have no idea what's causing the performance melt-down, but regressing 
back to that commit fixes it, again with no changes to the

  application in question.

I will try creeping forward from this commit to see if I can narrow it 
down.  Blah.



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



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

Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recent

[Josh Blum]

On 02/05/2012 12:49 PM, Marcus D. Leech wrote:
> I have an application, SIDSuite, that I've been running on my hardware
> here for about 18 months continuously, with reasonable performance
>   (the UI isn't totally-snappy, but acceptable).  Some time recently,
> with an upgrade of Gnu Radio, the performance became utterly
>   unacceptable--the UI became unusable, and updates to the FFT and
> Waterfall sinks became very "chunky".  I haven't changed the
>   app in months and months.
> 
> So, I started taking my Gnu Radio back further and further in time,
> until I was back to "normal".  I had to regress my GIT tree back to:
> 
> commit 2ed887b69a3b15840830998c4e6157176d427f60
> Author: Josh Blum 
> Date:   Sat Dec 31 13:06:01 2011 -0800
> 
> In order to get decent performance again.
> 
> I have no idea what's causing the performance melt-down, but regressing
> back to that commit fixes it, again with no changes to the
>   application in question.
> 
> I will try creeping forward from this commit to see if I can narrow it
> down.  Blah.
> 
> 

See if it was this merge: ab7cfce4a78dbb95a7c8871f56f4cb037e5b1bb2

>From the max outputs branch.

-Josh


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

Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recent

[Tom Rondeau]

On Sun, Feb 5, 2012 at 3:49 PM, Marcus D. Leech  wrote:

> I have an application, SIDSuite, that I've been running on my hardware
> here for about 18 months continuously, with reasonable performance
>  (the UI isn't totally-snappy, but acceptable).  Some time recently, with
> an upgrade of Gnu Radio, the performance became utterly
>  unacceptable--the UI became unusable, and updates to the FFT and
> Waterfall sinks became very "chunky".  I haven't changed the
>  app in months and months.
>
> So, I started taking my Gnu Radio back further and further in time, until
> I was back to "normal".  I had to regress my GIT tree back to:
>
> commit 2ed887b69a3b15840830998c4e6157**176d427f60
> Author: Josh Blum 
> Date:   Sat Dec 31 13:06:01 2011 -0800
>
> In order to get decent performance again.
>
> I have no idea what's causing the performance melt-down, but regressing
> back to that commit fixes it, again with no changes to the
>  application in question.
>
> I will try creeping forward from this commit to see if I can narrow it
> down.  Blah.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org



The only addition that I can think of is the max_noutputs addition that
went into the scheduler, which was merge:
ab7cfce4a78dbb95a7c8871f56f4cb037e5b1bb2
Made on Jan 3.

All this does is add a std::min check in line for sources and normal
blocks, though, and on my machines showed absolutely no
performance degradation. If this is seriously what's causing your problems,
then you must have been right on the edge performance-wise and these few
added cycles took you over the top.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recent

[Marcus D. Leech]

On 02/05/2012 04:08 PM, Tom Rondeau wrote:
On Sun, Feb 5, 2012 at 3:49 PM, Marcus D. Leech > wrote:


I have an application, SIDSuite, that I've been running on my
hardware here for about 18 months continuously, with reasonable
performance
 (the UI isn't totally-snappy, but acceptable).  Some time
recently, with an upgrade of Gnu Radio, the performance became utterly
 unacceptable--the UI became unusable, and updates to the FFT and
Waterfall sinks became very "chunky".  I haven't changed the
 app in months and months.

So, I started taking my Gnu Radio back further and further in
time, until I was back to "normal".  I had to regress my GIT tree
back to:

commit 2ed887b69a3b15840830998c4e6157176d427f60
Author: Josh Blum mailto:j...@joshknows.com>>
Date:   Sat Dec 31 13:06:01 2011 -0800

In order to get decent performance again.

I have no idea what's causing the performance melt-down, but
regressing back to that commit fixes it, again with no changes to the
 application in question.

I will try creeping forward from this commit to see if I can
narrow it down.  Blah.


-- 
Marcus Leech

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



The only addition that I can think of is the max_noutputs addition 
that went into the scheduler, which was merge:

ab7cfce4a78dbb95a7c8871f56f4cb037e5b1bb2
Made on Jan 3.

All this does is add a std::min check in line for sources and normal 
blocks, though, and on my machines showed absolutely no 
performance degradation. If this is seriously what's causing your 
problems, then you must have been right on the edge performance-wise 
and these few added cycles took you over the top.


Tom

That doesn't appear to be it.  Just built and installed that, and app is 
still fine.  Fast-forwarding a little bit and see what happens.




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

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

Re: [Discuss-gnuradio] Compile-time errors and coredumps disappeared, but WBX not accessible

[Jiri Pittner]

Hi Ben,
good news - the cmake-built gnuradio does not crash. However, I am not 
completely happy yet: when I try some WFM receive example, it always 
reports "frequency out of range". I have WBX in side A and DBSRX in side B 
of USRP1. uhd_usrp_probe recognizes this well:

...
|   |   |/
|   |   |   |   RX Subdev: 0
|   |   |   |   Name: WBX RX v2 + Simple GDB
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 68.750 to 2200.000 Mhz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
...
But even using option -a A:0 for gnuradio/gr-uhd/examples/usrp_wfm_rcv.py 
does not help, it always obviously tries to access DBSRX, which is 
inappropriate for this freq. Any idea what could be wrong?


Best regards,
Jiri

On Fri, 3 Feb 2012, Ben Hilburn wrote:


Jiri -

Just to echo Marcus, have you tried building with CMake?  Many people find
that the CMake build magically fixes bizarre build errors; it certainly
does in my case!

Cheers,
Ben

On Fri, Feb 3, 2012 at 8:59 AM, Jiri Pittner wrote:


Hi Volker,

thanks for the hints. I have presently 3 versions of boost:
Installed versions:  1.42.0(1.42)(19:46:44 5.3.2011)(python -examples)
1.46.1(1.46)(23:21:11 11.5.2011)(python -examples) 1.47.0(1.47)(14:25:38
1.11.2011)(python -examples)
and I am using eselect to switch between. I can try to emerge --sync and
install boost-1.47.0-r1 (not a typo from 1.48.0-r1?).
I have automake 1.11.1 and autoconf 2.68. No problems with make install
encountered.

Best regards,
Jiri


On Fri, 3 Feb 2012, Volker Schroer wrote:

 Hi Jiri,


I'm using gentoo, too and it compiles with boost-1.47.0-r1. Do you have
some older files of boost installed while trying to compil with 1.47 ?

volk does not compile , because you have a 64 bit system.

I fixed this problem by deleting line 21 in  volk/gen/archs.xml before
runnig boostrap
 The line is

x86_64


I hope this helps.

What version of automake do you use ? I'm using 1.11.2 and getting
problems when running make install.

I'm curious if this happents on your system, too.

Volker


Am 03.02.2012 11:37, schrieb Jiri Pittner:


 After configuring current git version of Gnuradio as
 /configure --enable-gr-uhd --enable-gr-noaa --enable-usrp2 --enable-usrp
 --enable-gr-usrp --enable-grc --enable-gr-audio-alsa --enable-gr-trellis
 --disable-volk
 and running make, while boost-1.47 is installed, I am getting the
 following error:

 libtool: link: ( cd ".libs" && rm -f "libgruel.la" && ln -s
 "../libgruel.la" "libgruel.la" )
 /bin/sh ../../../libtool --tag=CXX   --mode=link g++ -g -O2  -Wall
 -Woverloaded-virtual -Wno-uninitialized -pthread   -o test_gruel
 test_gruel.o -lboost_thread-1_42 -lboost_system-1_42
 -lboost_filesystem-1_42 pmt/libpmt-qa.la libgruel.la -lltdl
 libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -Wno-uninitialized
 -pthread -o .libs/test_gruel test_gruel.o  pmt/.libs/libpmt-qa.a
 -L/usr/lib64 /usr/lib64/libcppunit.so ./.libs/libgruel.so
 -lboost_system-1_42 -lboost_filesystem-1_42 -lboost_thread-1_42
 /usr/lib64/libltdl.so -ldl -pthread
 test_gruel.o: In function `current_path':
 /usr/include/boost/filesystem/**v3/operations.hpp:348: undefined
reference
 to `boost::filesystem3::detail::**current_path(boost::system::**
error_code*)'
 test_gruel.o: In function
 `boost::filesystem3::operator/**(boost::filesystem3::path const&,
 boost::filesystem3::path const&)':
 /usr/include/boost/filesystem/**v3/path.hpp:584: undefined reference to
 `boost::filesystem3::path::**operator/=(boost::filesystem3:**:path
const&)'
 test_gruel.o: In function `is_directory':
 /usr/include/boost/filesystem/**v3/operations.hpp:223: undefined
reference
 to `boost::filesystem3::detail::**status(boost::filesystem3::**path
const&,
 boost::system::error_code*)'
 test_gruel.o: In function `create_directory':
 /usr/include/boost/filesystem/**v3/operations.hpp:324: undefined
reference
 to `boost::filesystem3::detail::**create_directory(boost::**
filesystem3::path
 const&, boost::system::error_code*)'
 test_gruel.o: In function
 `boost::filesystem3::operator/**(boost::filesystem3::path const&,
 boost::filesystem3::path const&)':
 /usr/include/boost/filesystem/**v3/path.hpp:584: undefined reference to
 `boost::filesystem3::path::**operator/=(boost::filesystem3:**:path
const&)'
 test_gruel.o: In function `__static_initialization_and_**
destruction_0':
 /usr/include/boost/system/**error_code.hpp:214: undefined reference to
 `boost::system::generic_**category()'
 /usr/include/boost/system/**error_code.hpp:215: undefined reference to
 `boost::system::generic_**category()'
 /usr/include/boost/system/**error_code.hpp:216: undefined reference to
 `boost::system::system_**category()'
 collect2: ld returned 1 exit status
 make[7]: *** [test_gruel] Error 1
 make[7]: Leaving directory `/scratch/jiri/gnuradio/gruel/**src/lib'

 With boost-1.46 it fails the same way. With boost-1.42 it 

Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recent

[Marcus D. Leech]

On 02/05/2012 04:08 PM, Tom Rondeau wrote:

So, what if it was your *own* commit that seemed to be causing a 
problem?  Wouldn't that be embarrassing?  I think so :-( :-(


commit 2a2411a598c222e2ef82b857c0b53e0a9d1daf3f
Author: Marcus Leech 
Date:   Sun Jan 15 23:49:52 2012 -0500

core: fix for off-by-one issue in strip chart. Increases buffer 
size for longer displays.




I have no idea why this should be a problem, the buffer-shifting for 
stripchart mode is all done on the C++ side, and the updates are
  done at a fairly lazy rate (a few Hz).  So it's probably an issue on 
the Python side with bigger plot buffers.  Perhaps there's some kind of
  N**2 scaling ugliness going on that wasn't immediately obvious to me 
when I did that patch.


I think ultimately, the plotting stuff has to move so that most of the 
computational stuff is done in C++ land, with only the thinnest pieces

  done on the Python side.




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



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

Re: [Discuss-gnuradio] Compile-time errors and coredumps disappeared, but WBX not accessible

[Marcus D. Leech]

On 02/05/2012 04:43 PM, Jiri Pittner wrote:

Hi Ben,
good news - the cmake-built gnuradio does not crash. However, I am not 
completely happy yet: when I try some WFM receive example, it always 
reports "frequency out of range". I have WBX in side A and DBSRX in 
side B of USRP1. uhd_usrp_probe recognizes this well:



You're confusing "--spec" and "-a":

Usage: usrp_wfm_rcv.py [options]

Options:
  -h, --helpshow this help message and exit
  -a ARGS, --args=ARGS  UHD device address args [default=]
  --spec=SPEC   Subdevice of UHD device where appropriate
  -A ANTENNA, --antenna=ANTENNA
select Rx Antenna where appropriate
  -f FREQ, --freq=FREQ  set frequency to FREQ
  -g GAIN, --gain=GAIN  set gain in dB (default is midpoint)
  -V VOLUME, --volume=VOLUME
set volume (default is midpoint)
  -O AUDIO_OUTPUT, --audio-output=AUDIO_OUTPUT
pcm device name.  E.g., hw:0,0 or surround51 or
/dev/dsp
  --freq-min=FREQ_MIN   Set a minimum frequency [default=8790.0]
  --freq-max=FREQ_MAX   Set a maximum frequency [default=10810.0]


Try:

usrp_wfm_rcv.py -a "type=usrp1" -spec "A:0" -A RX2 --freq 92.5e6

Which will use the daughtercard in slot "A" with antenna "RX2" on a 
"type=usrp1" device.



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



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

Re: [Discuss-gnuradio] Compile-time errors and coredumps disappeared, but WBX not accessible

[Jiri Pittner]

Sorry for trivial question - it's my first time with UHD. It works now, 
thanks.

Jiri


On Sun, 5 Feb 2012, Marcus D. Leech wrote:


On 02/05/2012 04:43 PM, Jiri Pittner wrote:

 Hi Ben,
 good news - the cmake-built gnuradio does not crash. However, I am not
 completely happy yet: when I try some WFM receive example, it always
 reports "frequency out of range". I have WBX in side A and DBSRX in side B
 of USRP1. uhd_usrp_probe recognizes this well:


You're confusing "--spec" and "-a":

Usage: usrp_wfm_rcv.py [options]

Options:
  -h, --helpshow this help message and exit
  -a ARGS, --args=ARGS  UHD device address args [default=]
  --spec=SPEC   Subdevice of UHD device where appropriate
  -A ANTENNA, --antenna=ANTENNA
select Rx Antenna where appropriate
  -f FREQ, --freq=FREQ  set frequency to FREQ
  -g GAIN, --gain=GAIN  set gain in dB (default is midpoint)
  -V VOLUME, --volume=VOLUME
set volume (default is midpoint)
  -O AUDIO_OUTPUT, --audio-output=AUDIO_OUTPUT
pcm device name.  E.g., hw:0,0 or surround51 or
/dev/dsp
  --freq-min=FREQ_MIN   Set a minimum frequency [default=8790.0]
  --freq-max=FREQ_MAX   Set a maximum frequency [default=10810.0]


Try:

usrp_wfm_rcv.py -a "type=usrp1" -spec "A:0" -A RX2 --freq 92.5e6

Which will use the daughtercard in slot "A" with antenna "RX2" on a 
"type=usrp1" device.



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



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




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

Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recent

[Marcus D. Leech]

On 02/05/2012 04:44 PM, Marcus D. Leech wrote:

On 02/05/2012 04:08 PM, Tom Rondeau wrote:

So, what if it was your *own* commit that seemed to be causing a 
problem?  Wouldn't that be embarrassing?  I think so :-( :-(


commit 2a2411a598c222e2ef82b857c0b53e0a9d1daf3f
Author: Marcus Leech 
Date:   Sun Jan 15 23:49:52 2012 -0500

core: fix for off-by-one issue in strip chart. Increases buffer 
size for longer displays.




I have no idea why this should be a problem, the buffer-shifting for 
stripchart mode is all done on the C++ side, and the updates are
  done at a fairly lazy rate (a few Hz).  So it's probably an issue on 
the Python side with bigger plot buffers.  Perhaps there's some kind of
  N**2 scaling ugliness going on that wasn't immediately obvious to me 
when I did that patch.


I think ultimately, the plotting stuff has to move so that most of the 
computational stuff is done in C++ land, with only the thinnest pieces

  done on the Python side.




So performance degradation seems to scale with the size of 
OUTPUT_RECORD_SIZE in gr_oscope_guts.cc.  This basically determines how
  big the messages are that are sent along to the plotter routines in 
Python, but the STRIPCHART routine uses it to store the strip-chart

  samples in.


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



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

Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recent

[Tom Rondeau]

On Sun, Feb 5, 2012 at 5:07 PM, Marcus D. Leech  wrote:

> On 02/05/2012 04:44 PM, Marcus D. Leech wrote:
>
>> On 02/05/2012 04:08 PM, Tom Rondeau wrote:
>>
>> So, what if it was your *own* commit that seemed to be causing a problem?
>>  Wouldn't that be embarrassing?  I think so :-( :-(
>>
>> commit 2a2411a598c222e2ef82b857c0b53e**0a9d1daf3f
>> Author: Marcus Leech 
>> Date:   Sun Jan 15 23:49:52 2012 -0500
>>
>>core: fix for off-by-one issue in strip chart. Increases buffer size
>> for longer displays.
>>
>>
>>
>> I have no idea why this should be a problem, the buffer-shifting for
>> stripchart mode is all done on the C++ side, and the updates are
>>  done at a fairly lazy rate (a few Hz).  So it's probably an issue on the
>> Python side with bigger plot buffers.  Perhaps there's some kind of
>>  N**2 scaling ugliness going on that wasn't immediately obvious to me
>> when I did that patch.
>>
>> I think ultimately, the plotting stuff has to move so that most of the
>> computational stuff is done in C++ land, with only the thinnest pieces
>>  done on the Python side.
>>
>>
>>
>>
>>  So performance degradation seems to scale with the size of
> OUTPUT_RECORD_SIZE in gr_oscope_guts.cc.  This basically determines how
>  big the messages are that are sent along to the plotter routines in
> Python, but the STRIPCHART routine uses it to store the strip-chart
>  samples in.
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>


It sounds like we need someone to work on a strip-chart functionality for
the qtgui sinks. They do everything in C++ land, so we could optimize there
more easily.

In other news, glad you found the problem. What do you want to do about it
in the meantime, since it's your code, and I think you're the primary user
of the oscope under these conditions.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Serious performance regression in Gnu Radio recent

[Marcus D. Leech]

On 02/05/2012 05:19 PM, Tom Rondeau wrote:



It sounds like we need someone to work on a strip-chart functionality 
for the qtgui sinks. They do everything in C++ land, so we could 
optimize there more easily.


In other news, glad you found the problem. What do you want to do 
about it in the meantime, since it's your code, and I think you're the 
primary user of the oscope under these conditions.


Tom

I've backed OUTPUT_RECORD_SIZE down to 4096 on my system here, and it 
has acceptable performance for me.  In the particular
  application at hand, there are six channels being displayed in a 
strip-chart, and the chart is updated at about 4Hz (I think, I'll have to
  check in the flow-graph).  Looking at the plotter code in 
scope_window.py there's a lot of computational goo going on in Python land,
  including iterating over the input message buffer*number of 
channels.  It's pretty ugly down there :-(




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



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