Re: [Discuss-gnuradio] ISWCS Ilmenau / GNU Radio Meetup

[Martin Braun (CEL)]

Hi list,

just to remind people of our GNU Radio / USRP users meetup in Ilmenau
next week, where this year's ISWCS is being held.
Here's the details:

When: August 27 (Tuesday)
Where: Pub Aqui (http://www.pub-aqui.de/)

If you already know you're coming, please drop me a note off-list, so we
can make an estimate for reservations.

MB


On Tue, Jul 30, 2013 at 11:49:05AM +0200, Martin Braun (CEL) wrote:
> Hi,
> 
> for anyone attending the ISWCS conference in Ilmenau this year, we will
> be doing a GNU Radio enthusiasts meetup on Tuesday, August 27th. The
> exact location is still to be determined, but I'd like to thank Andre
> Puschmann for squeezing this into a busy schedule.
> 
> This year's ISWCS has a special category: The demo session. Unlike
> regular paper sessions, people will be actually demo-ing working stuff,
> and some of these submissions will be using GNU Radio!
> 
> The meetup will be an informal evening in the pub with some beers and
> chatter about GNU Radio and related things. If you're just interested in
> meeting people from this list, that's also a fine reason to come. If you
> just want the beer, that's still good enough!
> 
> If you already know you'll be there, please drop me a line off-list.
> Perhaps we can manage an estimate for the number of people attending.
> 
> Cheers,
> Martin
> 
> -- 
> 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



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


-- 
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


pgpPvmhouajzH.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Booting Zynq/Gnuradio

[Jan Schiefer]

Hi everybody,

I was thrilled to find Jonathon's writeup, and I have been trying to get
the same setup working here. Some things I learned along the way:

- OpenEmbedded is very very cool!
- bitbake doesn't work on eCryptfs file systems, as its path length
restrictions are not acceptable. One needs to build somewhere else (or at
least put the TMP and SSTATE-CACHE directories elsewhere).
- On my system (Ubuntu 12.04 64-bit), there was no binary called gmake,
which caused problems when generating the bit file with the Xilinx tool
chain. Solved this by linking /usr/bin/make to /usr/bin/gmake

Now, many many CPU cycles later, I am at the point of booting it. Well,
almost. What happens is that Das U-Boot is looking for an initial ramdisk:

U-Boot 2013.01 (Aug 17 2013 - 06:32:40)

DRAM:  512 MiB
WARNING: Caches not enabled
MMC:   zynq_sdhci: 0
SF: Detected S25FL256S with page size 64 KiB, total 32 MiB
In:serial
Out:   serial
Err:   serial
Net:   Gem.e000b000
Hit any key to stop autoboot:  0
Copying Linux from SD to RAM...
Device: zynq_sdhci
Manufacturer ID: 1b
OEM: 534d
Name: 0
Tran Speed: 5000
Rd Block Len: 512
SD version 2.0
High Capacity: Yes
Capacity: 3.7 GiB
Bus Width: 4-bit
reading uImage
2855496 bytes read in 415 ms (6.6 MiB/s)
reading devicetree.dtb
21734 bytes read in 19 ms (1.1 MiB/s)
reading uramdisk.image.gz
** Unable to read file uramdisk.image.gz **
zynq-uboot>

Why? Because the environment says so:
sdboot=echo Copying Linux from SD to RAM... && mmcinfo && fatload mmc 0
0x300 ${kernel_image} && fatload mmc 0 0x2A0 ${devicetree_image}
&& fatload mmc 0 0x200 ${ramdisk_image} && bootm 0x300 - 0x2A0

That doesn't seem quite right, I am assuming this should use the rootfs in
the rootfs partition, shouldn't it?

So my question is, am I missing something, or is the zynq Wiki page
missing a little section on how to set up the U-Boot environment variables
in the flash?

Again, thanks for the great work, this is exciting stuff!

Regards,
   Jan, ac7td




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

[Discuss-gnuradio] Initialize parameter of preloaded items

[Manoj Gudi]

For example:
https://github.com/guruofquality/gras/blob/master/tests/block_test.py#L54

Suppose I wanted the preloaded input to be 5 (instead of default 0), how do
I do it?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Booting Zynq/Gnuradio

[Philip Balister]

On 08/20/2013 04:32 AM, Jan Schiefer wrote:
> Hi everybody,
> 
> I was thrilled to find Jonathon's writeup, and I have been trying to get
> the same setup working here. Some things I learned along the way:
> 
> - OpenEmbedded is very very cool!
> - bitbake doesn't work on eCryptfs file systems, as its path length
> restrictions are not acceptable. One needs to build somewhere else (or at
> least put the TMP and SSTATE-CACHE directories elsewhere).
> - On my system (Ubuntu 12.04 64-bit), there was no binary called gmake,
> which caused problems when generating the bit file with the Xilinx tool
> chain. Solved this by linking /usr/bin/make to /usr/bin/gmake
> 
> Now, many many CPU cycles later, I am at the point of booting it. Well,
> almost. What happens is that Das U-Boot is looking for an initial ramdisk:
> 
> U-Boot 2013.01 (Aug 17 2013 - 06:32:40)
> 
> DRAM:  512 MiB
> WARNING: Caches not enabled
> MMC:   zynq_sdhci: 0
> SF: Detected S25FL256S with page size 64 KiB, total 32 MiB
> In:serial
> Out:   serial
> Err:   serial
> Net:   Gem.e000b000
> Hit any key to stop autoboot:  0
> Copying Linux from SD to RAM...
> Device: zynq_sdhci
> Manufacturer ID: 1b
> OEM: 534d
> Name: 0
> Tran Speed: 5000
> Rd Block Len: 512
> SD version 2.0
> High Capacity: Yes
> Capacity: 3.7 GiB
> Bus Width: 4-bit
> reading uImage
> 2855496 bytes read in 415 ms (6.6 MiB/s)
> reading devicetree.dtb
> 21734 bytes read in 19 ms (1.1 MiB/s)
> reading uramdisk.image.gz
> ** Unable to read file uramdisk.image.gz **
> zynq-uboot>
> 
> Why? Because the environment says so:
> sdboot=echo Copying Linux from SD to RAM... && mmcinfo && fatload mmc 0
> 0x300 ${kernel_image} && fatload mmc 0 0x2A0 ${devicetree_image}
> && fatload mmc 0 0x200 ${ramdisk_image} && bootm 0x300 - 0x2A0
> 
> That doesn't seem quite right, I am assuming this should use the rootfs in
> the rootfs partition, shouldn't it?
> 
> So my question is, am I missing something, or is the zynq Wiki page
> missing a little section on how to set up the U-Boot environment variables
> in the flash?

I assume you figured out you need to modify the bootm command so it does
not look for the ramdisk?  The default config from Xilinx is somewhat
obsessed with booting from a ramdisk :) I'm looking into some ways of
modifying the bootloader behavior without rebuilding it all the time.

What zynq hardware are you using?

Philip

> 
> Again, thanks for the great work, this is exciting stuff!
> 
> Regards,
>Jan, ac7td
> 
> 
> 
> 
> ___
> 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] Make tests failed when Building for version 3.7.1git

[Damon]

On Mon, Aug 19, 2013 at 8:29 AM, Damon  wrote:

Hi all,

I tried installing GNUradio v3.7.1git. The build completed, but several of
the build tests fail.

The OS is Ubuntu 12.04 32bit, with kernel version Linux
3.2.0-51-generic-pae. CPU is Intel® Core™ i7-3770 CPU @ 3.40GHz × 8 .

The prerequisites were built by :
apt-get install libfontconfig1-dev libxrender-dev libpulse-dev swig g++ \
automake autoconf libtool python-dev libfftw3-dev \
libcppunit-dev libboost1.48-all-dev libusb-dev libusb-1.0-0-dev fort77 \
libsdl1.2-dev python-wxgtk2.8 git-core \
libqt4-dev python-numpy ccache python-opengl libgsl0-dev \
python-cheetah python-lxml doxygen qt4-dev-tools libusb-1.0-0-dev \
libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4 \
cmake git-core wget libxi-dev python-docutils gtk2-engines-pixbuf r-base-dev
python-tk \
liborc-0.4-0 liborc-0.4-dev libasound2-dev python-gtk2

then I ran cmake, make and make test.
The following tests FAILED:
   1 - qa_volk_test_all (Failed)
  85 - qa_freq_xlating_fir_filter (Failed)
  93 - qa_fir_filter (Failed)
 167 - qa_codec2_vocoder (Failed)
So  I ran:
ctest --output-on-failure -O ctest_log_file
Attached please find the log file.

How to fix it?

Best regards,
Damon

Damon,

Thanks for the detailed report. Can you try uninstalling ORC and
rebuilding without it? It looks like those errors might be related to
differences in precision/rounding with ORC.

And ignore the codec2 problem, unless you specifically want to use
codec2. It's a known problem, but we don't have a fix for it, yet.



Hi Tom,

There are 2 orc installed: liborc-0.4-0 and liborc-0.4-dev.
I uninstalled liborc-0.4-dev, rebuilt gnuradio. The volk passed
test. But several tests failed:
 85 - qa_freq_xlating_fir_filter (Failed)
 93 - qa_fir_filter (Failed)
167 - qa_codec2_vocoder (Failed)
Attached please find the log file: ctest_log_file.

In my another computer, I uninstalled both liborc-0.4-0 and liborc-0.4-dev.
Then I rebuilt uhd and gnuradio v3.7.0. Three tests mentioned above 
failed too.

Attached please find the log file: ctest_log_file2.

Any suggestions?

Thanks,
Damon

[HANDLER_OUTPUT] 
Test project /root/gnuradio/build

Start   1: qa_volk_test_all
  1/176 Test   #1: qa_volk_test_all .   Passed0.76 sec
Start   2: gr-runtime-test
  2/176 Test   #2: gr-runtime-test ..   Passed3.07 sec
Start   3: gr-pmt-test
  3/176 Test   #3: gr-pmt-test ..   Passed1.02 sec
Start   4: qa_feval
  4/176 Test   #4: qa_feval .   Passed0.81 sec
Start   5: qa_kludged_imports
  5/176 Test   #5: qa_kludged_imports ...   Passed0.09 sec
Start   6: qa_tag_utils
  6/176 Test   #6: qa_tag_utils .   Passed0.09 sec
Start   7: qa_pmt_to_python
  7/176 Test   #7: qa_pmt_to_python .   Passed0.07 sec
Start   8: qa_pmt
  8/176 Test   #8: qa_pmt ...   Passed0.08 sec
Start   9: test_gr_blocks
  9/176 Test   #9: test_gr_blocks ...   Passed0.48 sec
Start  10: qa_file_metadata
 10/176 Test  #10: qa_file_metadata .   Passed0.22 sec
Start  11: qa_moving_average
 11/176 Test  #11: qa_moving_average    Passed0.22 sec
Start  12: qa_sample_and_hold
 12/176 Test  #12: qa_sample_and_hold ...   Passed0.13 sec
Start  13: qa_skiphead
 13/176 Test  #13: qa_skiphead ..   Passed0.28 sec
Start  14: qa_keep_m_in_n
 14/176 Test  #14: qa_keep_m_in_n ...   Passed0.14 sec
Start  15: qa_vector_map
 15/176 Test  #15: qa_vector_map    Passed0.14 sec
Start  16: qa_transcendental
 16/176 Test  #16: qa_transcendental    Passed0.14 sec
Start  17: qa_copy
 17/176 Test  #17: qa_copy ..   Passed0.15 sec
Start  18: qa_vco
 18/176 Test  #18: qa_vco ...   Passed0.14 sec
Start  19: qa_interleave
 19/176 Test  #19: qa_interleave    Passed0.13 sec
Start  20: qa_add_mult_v
 20/176 Test  #20: qa_add_mult_v    Passed0.29 sec
Start  21: qa_packed_to_unpacked
 21/176 Test  #21: qa_packed_to_unpacked    Passed0.20 sec
Start  22: qa_burst_tagger
 22/176 Test  #22: qa_burst_tagger ..   Passed0.13 sec
Start  23: qa_multiply_conjugate
 23/176 Test  #23: qa_multiply_conjugate    Passed0.13 sec
Start  24: qa_max
 24/176 Test  #24: qa_max ...   Passed0.14 sec
Start  25: qa_file_source_sink
 25/176 Test  #25: qa_file_source_sink ..   Passed0.29 sec
Start  26: qa_keep_one_in_n
 26/176 Test  #26: qa_keep_one_in_n 

[Discuss-gnuradio] SDR front end design.

[Peter Reilley]

Hello;
 
I am interested in designing a front end amplifier for a SDR.   I am
interested
in the frequency band from 2 MHz to about 60 MHz.   Is there anyone
interested 
this in frequency band and is doing hardware design?   I would like to
discuss 
design issues and problems.
 
Or, is there a better forum for this type of discussion?
 
Thanks,
Pete.
 
 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] one thread is not always scheduled

[Pengyu Zhang]

Hi,

I build a signal processing pipeline on USRP: RX --> decoder --> protocol
--> TX. I used STS scheduler to schedule those signal processing blocks.
When the amount of data that goes into the decoder module is larger than a
fixed number, the decoder thread is scheduled to run for a while, decodes
the initial part of the incoming data, and is not scheduled anymore before
it finishes processing the rest of the incoming data.

I'm a bit surprised to observe that one thread is not always scheduled by
the scheduler. Does anyone have some ideas on how to tackle this problem?
Thanks.

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

[Discuss-gnuradio] New Email

[Michael Dickens]

I have been contracted by Ettus Research to help maintain UHD and GNU Radio on 
Mac OS X, and have new contact email for this position: < 
michael.dick...@ettus.com >.  I have (re)subscribed to this list using my new 
email contact.  If you use any version of Mac OS X with UHD and/or GNU Radio, 
whether installing from binary or source, using MacPorts, HomeBrew, Fink, or 
some other means, and you have issues and/or questions, please feel free to 
contact me at any of my email addresses or via this list.  I will reply back 
from my ettus.com email.  Please note that discussions for this specific list 
should be primarily about GNU Radio, but any background dependency issues are 
also fair game -- though expect the discussion to go off-list quickly.  In 
general, UHD and GNU Radio work well on Mac OS X, so this is expected to be 
very part-time work for me when averaged over months.

On my queue right now are three primary items:

(1) In MacPorts, the WX ports are dysfunctional as well as some currently fail 
to build.  I am working with the primary MacPorts developer of these ports to 
resolve this issue as quickly as we can.  He has done most of the work to date, 
with me mostly contributing advice but also a little programming assistance.  I 
have verified that UHD and the various GNU Radio ports work with this new 
setup; it's mostly now a matter of time and some small tweaks before this 
change is merged with the MacPorts trunk.

(2) At least for me, "make test" fails on Mac OS X unless "make install" is 
performed first.  I'm looking into reworking parts of the CMake configure 
scripts to handle testing more robustly.

(3) Mac OS X audio sink and/or source is reportedly not working correctly for 
all sample rates.  I'm looking into reworking parts of the OSX audio sink 
and/or source to handle sample rates more robustly, as well as handle some 
other situations and provide some new features.

I look forward to hearing from Mac OS X users, hopefully mostly your successes 
but also issues if you have any beyond those listed above as well as 
suggestions for other additions into MacPorts to make your life easier. - MLD


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

Re: [Discuss-gnuradio] How to use gr-audio on Windows?

[Tom Rondeau]

On Mon, Aug 19, 2013 at 8:12 PM, Luong Tan Phong  wrote:
> My problem here:
>
> On Windows PC1, I've install gnuradio with gr-audio (using portaudio) from
> source code, write a program to read data from LineIn port on sound card.
> Every thing is OK.
>
> On Windows PC2:
>1. I copy the gnuradio dlls from PC1 to PC2 (don't install gnuradio),
> included portaudio.dll, QT4Core.dll, ...
>2. Create a directory named .gnuradio in my %HOME%, here
> C:\Users\LTP\.gnuradio. In this directory create a file named config.conf.
> Set audio_module = portaudio.
>3. Copy my program from PC1 to PC2. The program can run but it can't read
> data from LineIn port on sound card.
>
> Could you help me, please?
>
> LTP.

This sounds like a problem with portaudio. I would install portaudio
properly on PC2 and test it to make sure it's working.

Tom



> On Mon, Aug 19, 2013 at 10:58 PM, Tom Rondeau  wrote:
>>
>> On Wed, Aug 14, 2013 at 8:04 PM, Luong Tan Phong 
>> wrote:
>> > Sorry for my misstake.
>> >
>> > When I move my program to new PC, it can't read data from soundcard.
>>
>> I'm still a little confused.
>>
>> You have a Windows machine that you can use with gr-audio.
>>
>> You have a /second/ Windows machine that cannot use gr-audio.
>>
>> Right?
>>
>> As I said, the native Windows interface in gr-audio does not work. But
>> if you are using portaudio on one Windows machine, make sure your
>> other machine is set up the exact same way to use portaudio there,
>> too.
>>
>> Tom
>>
>>
>> > On Aug 15, 2013 7:01 AM, "Luong Tan Phong"  wrote:
>> >>
>> >> On the PC has installed gnuradio with portaudio, the 'audio_mode' has
>> >> set
>> >> portaudio in gr-audio.conf file.
>> >> When I move my program to a new PC, it can read data from soundcard and
>> >> I
>> >> don't know how to use gr-audio.conf file to configure gr-audio (where
>> >> to set
>> >> file conf, using it).
>> >> Could you help me,  please?
>> >>
>> >> Thanks so much.
>> >>
>> >> Best regards.
>> >>
>> >> LTP.
>> >>
>> >> On Aug 15, 2013 4:31 AM, "Tom Rondeau"  wrote:
>> >>>
>> >>> On Tue, Aug 13, 2013 at 4:39 AM, Luong Tan Phong 
>> >>> wrote:
>> >>> > Hi Lists,
>> >>> >
>> >>> > I've install gnuradio on Windows following the link:
>> >>> >
>> >>> >
>> >>> > http://voltronics.blogspot.com/2013/01/gnu-radio-windows-build-guide.html.
>> >>> > It's OK.After that, I've write program to read data from soundcard
>> >>> > with
>> >>> > gr-audio lib. It's OK (using portaudio lib).
>> >>> >
>> >>> > When I copy the program and all dll from gnuradio, QT,... into a
>> >>> > directory
>> >>> > on another PC, the program can run but it can't read data from
>> >>> > soundcard.
>> >>> >
>> >>> > Could you help me, please?
>> >>> >
>> >>> > Best regards.
>> >>> >
>> >>> > LTP.
>> >>>
>> >>> Windows native audio is currently not implemented (see But 521 on our
>> >>> issues tracker). We need someone willing to work on it to see if we
>> >>> can fix it.
>> >>>
>> >>> But it sounds like you had it working using portaudio, so maybe you
>> >>> just need to get portaudio working properly on the new machine. And
>> >>> look at the installed gr-audio.conf file to set 'audio_mode' to
>> >>> portaudio to make sure you're properly selecting that.
>> >>>
>> >>> --
>> >>> Tom
>> >>> Visit us at GRCon13 Oct. 1 - 4
>> >>> http://www.trondeau.com/grcon13
>>
>>
>>
>> --
>> Tom
>> Visit us at GRCon13 Oct. 1 - 4
>> http://www.trondeau.com/grcon13
>
>



-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] one thread is not always scheduled

[Tom Rondeau]

On Tue, Aug 20, 2013 at 10:25 AM, Pengyu Zhang  wrote:
> Hi,
>
> I build a signal processing pipeline on USRP: RX --> decoder --> protocol
> --> TX. I used STS scheduler to schedule those signal processing blocks.
> When the amount of data that goes into the decoder module is larger than a
> fixed number, the decoder thread is scheduled to run for a while, decodes
> the initial part of the incoming data, and is not scheduled anymore before
> it finishes processing the rest of the incoming data.
>
> I'm a bit surprised to observe that one thread is not always scheduled by
> the scheduler. Does anyone have some ideas on how to tackle this problem?
> Thanks.
>
> Pengyu


I don't follow. How many threads are run? You said 'not always' but
that doesn't make any sense. Are you sure it's not consistent between
runs? Are you sure you are always using the STS scheduler (and if so,
why?)?

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] Booting Zynq/Gnuradio

[Jan Schiefer]

> On 08/20/2013 04:32 AM, Jan Schiefer wrote:
>>
>> Now, many many CPU cycles later, I am at the point of booting it. Well,
>> almost. What happens is that Das U-Boot is looking for an initial
>> ramdisk:
>>
>> U-Boot 2013.01 (Aug 17 2013 - 06:32:40)
>>
>> DRAM:  512 MiB
>> WARNING: Caches not enabled
>> MMC:   zynq_sdhci: 0
>> SF: Detected S25FL256S with page size 64 KiB, total 32 MiB
>> In:serial
>> Out:   serial
>> Err:   serial
>> Net:   Gem.e000b000
>> Hit any key to stop autoboot:  0
>> Copying Linux from SD to RAM...
>> Device: zynq_sdhci
>> Manufacturer ID: 1b
>> OEM: 534d
>> Name: 0
>> Tran Speed: 5000
>> Rd Block Len: 512
>> SD version 2.0
>> High Capacity: Yes
>> Capacity: 3.7 GiB
>> Bus Width: 4-bit
>> reading uImage
>> 2855496 bytes read in 415 ms (6.6 MiB/s)
>> reading devicetree.dtb
>> 21734 bytes read in 19 ms (1.1 MiB/s)
>> reading uramdisk.image.gz
>> ** Unable to read file uramdisk.image.gz **
>> zynq-uboot>
>>
>> Why? Because the environment says so:
>> sdboot=echo Copying Linux from SD to RAM... && mmcinfo && fatload mmc 0
>> 0x300 ${kernel_image} && fatload mmc 0 0x2A0 ${devicetree_image}
>> && fatload mmc 0 0x200 ${ramdisk_image} && bootm 0x300 -
>> 0x2A0
>>
>> That doesn't seem quite right, I am assuming this should use the rootfs
>> in
>> the rootfs partition, shouldn't it?
>>
>> So my question is, am I missing something, or is the zynq Wiki page
>> missing a little section on how to set up the U-Boot environment
>> variables
>> in the flash?
>
> I assume you figured out you need to modify the bootm command so it does
> not look for the ramdisk?  The default config from Xilinx is somewhat
> obsessed with booting from a ramdisk :) I'm looking into some ways of
> modifying the bootloader behavior without rebuilding it all the time.
>
> What zynq hardware are you using?
>
> Philip
>

This is on a Zedboard. I did figure out that I need to change mboot
parameters, but I haven't studied the whole setup enough to know what all
else needs to change. So I thought I'd ask :-).

When you write about modifications, are you referring to more advanced
ways to load bitfiles rather than sticking them in the boot image?

Regards,
   Jan


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

Re: [Discuss-gnuradio] Booting Zynq/Gnuradio

[Jan Schiefer]

HI Ivan,

> I've been working through the wiki as well.  In my setup I had to also
> replace the FSBL with the default Xilinx one to get the system to boot
> (ZC702 eval board).  If you stop u-boot from autobooting you can go in and
> change the environment variables (printenv, setenv) and when you have
> everything setup you can 'saveenv' and the state will be saved to flash.
>
> Now the system boots smoothly.  Since I had some issues with the booting
> process I'm not sure if the system.bit file is loaded properly.  To make
> sure, I load the bit file using /dev/xdevcfg (have to mknod, convert .bit
> to .bin, etc.).  Then I insmod the user_peripheral.ko (had to copy it into
> /lib/modules/ for insmod to find it).

I was wondering how one would load a bit file after booting, so this
definitely a good tip. I will try that out once I get a little further
along.

Meanwhile I'll figure out the right boot environment variables for my
Zedboard next.

Thanks,
   Jan


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

Re: [Discuss-gnuradio] one thread is not always scheduled

[Pengyu Zhang]

I'm running Michael Buettner's RFID program.

https://www.cgran.org/wiki/Gen2

This program has many blocks:

rx --> matched_filt --> command_gate --> agc --> to_mag --> to_mag, center
--> mm --> tag_decoder --> self.reader --> amp --> to_complex --> tx

I'm always using the STS scheduler because that's the default configuration
to run Buettner's program. Before running the program, we
specify GR_SCHEDULER=STS. Are there drawbacks of using STS scheduler?

If the amount of data that goes into the tag_decoder module is smaller than
1000 bits, the whole program runs correctly because tag_decoder module is
scheduled several times to process all the incoming data. If the amount of
data is over 1000 bits, the tag_decoder module is scheduled several times
to process the first 1000 bits. However, the tag_decoder module never gets
a chance to be scheduled to process the rest of incoming data. Instead of
tag_decoder module, only self.reader module is always scheduled at that
point.



On Tue, Aug 20, 2013 at 11:05 AM, Tom Rondeau  wrote:

> On Tue, Aug 20, 2013 at 10:25 AM, Pengyu Zhang 
> wrote:
> > Hi,
> >
> > I build a signal processing pipeline on USRP: RX --> decoder --> protocol
> > --> TX. I used STS scheduler to schedule those signal processing blocks.
> > When the amount of data that goes into the decoder module is larger than
> a
> > fixed number, the decoder thread is scheduled to run for a while, decodes
> > the initial part of the incoming data, and is not scheduled anymore
> before
> > it finishes processing the rest of the incoming data.
> >
> > I'm a bit surprised to observe that one thread is not always scheduled by
> > the scheduler. Does anyone have some ideas on how to tackle this problem?
> > Thanks.
> >
> > Pengyu
>
>
> I don't follow. How many threads are run? You said 'not always' but
> that doesn't make any sense. Are you sure it's not consistent between
> runs? Are you sure you are always using the STS scheduler (and if so,
> why?)?
>
> --
> Tom
> Visit us at GRCon13 Oct. 1 - 4
> http://www.trondeau.com/grcon13
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Meaning of Center Frequency in QT GUI Sink / QT Waterfall Sink

[Tom Rondeau]

On Fri, Aug 16, 2013 at 1:43 AM, Volker Schroer  wrote:
> Am 14.08.2013 23:45, schrieb Tom Rondeau:
>
>> On Wed, Aug 14, 2013 at 6:29 AM, Volker Schroer  wrote:
>>>
>>> Hi,
>>>
>>> what is the meaning of the variable "Center Frequency" in the qt_gui_sink
>>> /
>>> qt_waterfall_sink ?
>>>
>>> If I remember well, in pre 3.7 version it served as base of the  x - axis
>>> legend.
>>>
>>> Now, if I choose a value > bandwidth/2 the spectrum will not be
>>> displayed.
>>>
>>> Do I misinterpret the meaning  of "Center Frequency" or is this a bug ?
>>>
>>> -- Volker
>>
>>
>> Volker,
>>
>> This sounds like a bug. Someone else reported some related issues with
>> this sink in 3.7, too. Probably a versioning issue that I didn't
>> properly take care of with the update.
>>
>> Now, the main reason this would have slipped through is because I'm
>> trying to get rid of the qt_gui_sink. Since I've split out the
>> different sinks, it doesn't make sense to keep them in two different
>> places with duplicated code that can't easily be shared (which can
>> then lead to mistakes like this). I will be moving to a new structure
>> for the qtgui_sink_X blocks that is just a tab container for the other
>> individual classes to simplify the code.
>>
>> Now, you're also saying that it's a problem with the
>> qt_waterfall_sink? That's more surprising, but again, probably a
>> Qt/Qwt version issue and should be a simple fix once identified. Not
>> sure when I'll be able to get to it, so either submit a patch or at
>> least open a bug report on our Issues Tracker to make sure I remember
>> to get to it soon.
>>
>> But remember, setting the center frequency is just a display issue. It
>> simply sets the tick labels on the x-axis and nothing more.
>>
> Tom,
>
> thanks for the info. I'll see if I can fix it, otherwise I'll report a bug.
>
> I'm using qwt-5.2 and pyqwt-5.2  on my system ( gentoo)
>
> -- Volker
>


Hi Volker,

Looks like this is specifically a Qwt 5.2 issue. I've resolved another
minor problem, but I'm seeing what you are seeing now by moving back
from Qwt 6. I'm working on a fix for it.

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] Booting Zynq/Gnuradio

[Ivan C.]

On Tue, Aug 20, 2013 at 11:19 AM, Jan Schiefer  wrote:
> HI Ivan,
>
>> I've been working through the wiki as well.  In my setup I had to also
>> replace the FSBL with the default Xilinx one to get the system to boot
>> (ZC702 eval board).  If you stop u-boot from autobooting you can go in and
>> change the environment variables (printenv, setenv) and when you have
>> everything setup you can 'saveenv' and the state will be saved to flash.
>>
>> Now the system boots smoothly.  Since I had some issues with the booting
>> process I'm not sure if the system.bit file is loaded properly.  To make
>> sure, I load the bit file using /dev/xdevcfg (have to mknod, convert .bit
>> to .bin, etc.).  Then I insmod the user_peripheral.ko (had to copy it into
>> /lib/modules/ for insmod to find it).
>
> I was wondering how one would load a bit file after booting, so this
> definitely a good tip. I will try that out once I get a little further
> along.
>
> Meanwhile I'll figure out the right boot environment variables for my
> Zedboard next.
>
> Thanks,
>Jan

Hi Jan,

Take a look at 
openembedded-core/build_zedboard/tmp-eglibc/work/zedboard_user_peripheral.../u-boot-xlnx/v2013.../include/configs/zynq_common.h

string search for /* Default environment */

After the system boots, I had to make a minor change to the fir filter
example.  On the ZC702, I was getting a segfault as udev wasn't
finding devcfg.

/sys/devices/amba.0/ lists f8007000.ps7-dev-cfg, modifying the call to
udev_enumerate_add_match_sysname to look for this device instead of
f8007000.devcfg and the example now works.  Thanks to Jon and company
for this work!

Regards,
Ivan

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

Re: [Discuss-gnuradio] Booting Zynq/Gnuradio

[Philip Balister]

On 08/20/2013 11:12 AM, Jan Schiefer wrote:
>> On 08/20/2013 04:32 AM, Jan Schiefer wrote:
>>>
>>> Now, many many CPU cycles later, I am at the point of booting it. Well,
>>> almost. What happens is that Das U-Boot is looking for an initial
>>> ramdisk:
>>>
>>> U-Boot 2013.01 (Aug 17 2013 - 06:32:40)
>>>
>>> DRAM:  512 MiB
>>> WARNING: Caches not enabled
>>> MMC:   zynq_sdhci: 0
>>> SF: Detected S25FL256S with page size 64 KiB, total 32 MiB
>>> In:serial
>>> Out:   serial
>>> Err:   serial
>>> Net:   Gem.e000b000
>>> Hit any key to stop autoboot:  0
>>> Copying Linux from SD to RAM...
>>> Device: zynq_sdhci
>>> Manufacturer ID: 1b
>>> OEM: 534d
>>> Name: 0
>>> Tran Speed: 5000
>>> Rd Block Len: 512
>>> SD version 2.0
>>> High Capacity: Yes
>>> Capacity: 3.7 GiB
>>> Bus Width: 4-bit
>>> reading uImage
>>> 2855496 bytes read in 415 ms (6.6 MiB/s)
>>> reading devicetree.dtb
>>> 21734 bytes read in 19 ms (1.1 MiB/s)
>>> reading uramdisk.image.gz
>>> ** Unable to read file uramdisk.image.gz **
>>> zynq-uboot>
>>>
>>> Why? Because the environment says so:
>>> sdboot=echo Copying Linux from SD to RAM... && mmcinfo && fatload mmc 0
>>> 0x300 ${kernel_image} && fatload mmc 0 0x2A0 ${devicetree_image}
>>> && fatload mmc 0 0x200 ${ramdisk_image} && bootm 0x300 -
>>> 0x2A0
>>>
>>> That doesn't seem quite right, I am assuming this should use the rootfs
>>> in
>>> the rootfs partition, shouldn't it?
>>>
>>> So my question is, am I missing something, or is the zynq Wiki page
>>> missing a little section on how to set up the U-Boot environment
>>> variables
>>> in the flash?
>>
>> I assume you figured out you need to modify the bootm command so it does
>> not look for the ramdisk?  The default config from Xilinx is somewhat
>> obsessed with booting from a ramdisk :) I'm looking into some ways of
>> modifying the bootloader behavior without rebuilding it all the time.
>>
>> What zynq hardware are you using?
>>
>> Philip
>>
> 
> This is on a Zedboard. I did figure out that I need to change mboot
> parameters, but I haven't studied the whole setup enough to know what all
> else needs to change. So I thought I'd ask :-).
> 
> When you write about modifications, are you referring to more advanced
> ways to load bitfiles rather than sticking them in the boot image?

Mods to fix the ramdisk issue.

You can load the bitfile from linux with cat foo.bin > /dev/xdevcfg

There is a magic promgen command to get the endianess correct though.
I'll take a look at the wiki page and see if we can document the magic
command there.

Philip[


> 
> Regards,
>Jan
> 
> 
> 

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

[Discuss-gnuradio] uhd_fft problems (runtime error)

[Victor User]

Hello, I'm new to using GNURadio and the USRP.

I'm running Fedora 17 with GNURadio (3.5.3.1) and UHD (3.4.3) installed with 
yum.  

I'm trying to run uhd_fft.py and I get the following error:

$ ./uhd_fft.py 
linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5); Boost_104800; 
UHD_003.004.003-0-unknown

Using Volk machine: sse4_1_64_orc
Traceback (most recent call last):
  File "./uhd_fft.py", line 180, in 
    tb = uhd_fft(gain=options.gain, freq=options.freq, address=options.address, 
samp_rate=options.samp_rate)
  File "./uhd_fft.py", line 110, in __init__
    channels=range(1),
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py", 
line 116, in constructor_interceptor
    return old_constructor(*args)
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", 
line 2296, in usrp_source
    return _uhd_swig.usrp_source(*args)
RuntimeError: send_to: Network is unreachable


I'm wondering if there is a mismatch on my UHD driver and the firmware/fpga 
images?

Because when I do:

$ uhd_find_devices 
linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5); Boost_104800; 
UHD_003.004.003-0-unknown

No UHD Devices Found

BUT:
$ uhd_find_devices --args="addr=192.168.10.2"
linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5); Boost_104800; 
UHD_003.004.003-0-unknown

--
-- UHD Device 0
--
Device Address:
    type: usrp2
    addr: 192.168.10.2
    name: 
    serial: E0R22N8UP


A similar thing happens when I run 'uhd_usrp_probe' ... if I do not specify the 
address then nothing is found, but if I supply the IP address then it prints 
out information that looks good.  

I can ping 192.168.10.2 successfully as well.

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

Re: [Discuss-gnuradio] Booting Zynq/Gnuradio

[jpendlum]

Hey Jan and others,

Thanks for the kind words. I am glad that people are finding my work useful.
:-)

Xilinx's meta-xilinx layer was recently updated which broke my u-boot patch
to boot from the SD card. I am working on a fix right now.

Meanwhile, you can manually boot to the SD card using "bootm 0x300 -
0x2A0"



Jon



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Booting-Zynq-Gnuradio-tp43234p43248.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] uhd_fft problems (runtime error)

[Marcus Müller]

Hi Victor,
this looks like a network malconfiguration.
With redhat/fedora-based Distributions usually a rather restrictive 
firewall is shipped, disabling a range of types of broadcast traffic.
The issue is described at 
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#firewall-issues ;

use the firewall administration utility to change the settings accordingly.

Greetings,
Marcus M
On 20.08.2013 19:13, Victor User wrote:

Hello, I'm new to using GNURadio and the USRP.

I'm running Fedora 17 with GNURadio (3.5.3.1) and UHD (3.4.3) 
installed with yum.


I'm trying to run uhd_fft.py and I get the following error:

$ ./uhd_fft.py
linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5); Boost_104800; 
UHD_003.004.003-0-unknown


Using Volk machine: sse4_1_64_orc
Traceback (most recent call last):
  File "./uhd_fft.py", line 180, in 
tb = uhd_fft(gain=options.gain, freq=options.freq, 
address=options.address, samp_rate=options.samp_rate)

  File "./uhd_fft.py", line 110, in __init__
channels=range(1),
  File 
"/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py", 
line 116, in constructor_interceptor

return old_constructor(*args)
  File 
"/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", 
line 2296, in usrp_source

return _uhd_swig.usrp_source(*args)
RuntimeError: send_to: Network is unreachable


I'm wondering if there is a mismatch on my UHD driver and the 
firmware/fpga images?


Because when I do:

$ uhd_find_devices
linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5); Boost_104800; 
UHD_003.004.003-0-unknown


No UHD Devices Found

BUT:
$ uhd_find_devices --args="addr=192.168.10.2"
linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5); Boost_104800; 
UHD_003.004.003-0-unknown


--
-- UHD Device 0
--
Device Address:
type: usrp2
addr: 192.168.10.2
name:
serial: E0R22N8UP


A similar thing happens when I run 'uhd_usrp_probe' ... if I do not 
specify the address then nothing is found, but if I supply the IP 
address then it prints out information that looks good.


I can ping 192.168.10.2 successfully as well.

Any ideas?
Thanks


___
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

[Discuss-gnuradio] gr_foo_sptr (vs) gr_foo

[NaceurElOuni]

Hello,

I did spent time working on GNU radio C++ API, 
And I was stuck debugging in some point where I need to get the gr_foo to
retrieve the values of its members whereas I already instantiated
gr_foo_sptr instead.
Is there a way to fix this issue. 

Example: I already instantiated gr_msg_queue_sptr, gr_message_source_sptr
...

  and I got ‘gr_msg_queue_sptr’ has no member named ‘empty_p’
   ‘gr_message_source_sptr’ has no member named
‘msgq’ 

Do I have to get rid of sptrs and instantiate gr_msg_queue and
gr_message_source instead
Or I may get around this.

Regards,



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gr-foo-sptr-vs-gr-foo-tp43252.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] uhd_fft problems (runtime error)

[Marcus D. Leech]

On 08/20/2013 01:27 PM, Marcus Müller wrote:

Hi Victor,
this looks like a network malconfiguration.
With redhat/fedora-based Distributions usually a rather restrictive 
firewall is shipped, disabling a range of types of broadcast traffic.
The issue is described at 
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#firewall-issues ;
use the firewall administration utility to change the settings 
accordingly.


Greetings,
Marcus M
On 20.08.2013 19:13, Victor User wrote:

Hello, I'm new to using GNURadio and the USRP.

I'm running Fedora 17 with GNURadio (3.5.3.1) and UHD (3.4.3) 
installed with yum.


I'm trying to run uhd_fft.py and I get the following error:

$ ./uhd_fft.py
linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5); 
Boost_104800; UHD_003.004.003-0-unknown


Using Volk machine: sse4_1_64_orc
Traceback (most recent call last):
  File "./uhd_fft.py", line 180, in 
tb = uhd_fft(gain=options.gain, freq=options.freq, 
address=options.address, samp_rate=options.samp_rate)

  File "./uhd_fft.py", line 110, in __init__
channels=range(1),
  File 
"/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py", 
line 116, in constructor_interceptor

return old_constructor(*args)
  File 
"/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", 
line 2296, in usrp_source

return _uhd_swig.usrp_source(*args)
RuntimeError: send_to: Network is unreachable
Basically what's going on is that UHD, when given no hint about what 
device to go looking for, goes down a list of things to try.
  When it tries to do a broadcast "probe" to find a USRP2 or N210 
device, it can get an error back from the kernel.


But if you use an *explicit* device address, you can avoid that problem.

You don't indicate what type of USRP you have, but:

uhd_fft --args "addr=192.168.10.2"

or

uhd_fft --args "type=b100"

or

uhd_fft --args "type=usrp1"

Will avoid this problem, as will tweaking your firewall and network 
configuration






--
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] gr_foo_sptr (vs) gr_foo

[Tom Rondeau]

On Tue, Aug 20, 2013 at 5:15 PM, NaceurElOuni  wrote:
> Hello,
>
> I did spent time working on GNU radio C++ API,
> And I was stuck debugging in some point where I need to get the gr_foo to
> retrieve the values of its members whereas I already instantiated
> gr_foo_sptr instead.
> Is there a way to fix this issue.
>
> Example: I already instantiated gr_msg_queue_sptr, gr_message_source_sptr
> ...
>
>   and I got ‘gr_msg_queue_sptr’ has no member named ‘empty_p’
>‘gr_message_source_sptr’ has no member named
> ‘msgq’
>
> Do I have to get rid of sptrs and instantiate gr_msg_queue and
> gr_message_source instead
> Or I may get around this.
>
> Regards,

Take a look at the Boost shared pointer documentation:
http://www.boost.org/doc/libs/1_54_0/libs/smart_ptr/shared_ptr.htm

You'll want to either use the '->' operator or you can get a pointer
to the original object using the get() function.

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] Make fails and gives the following

[Ben Hilburn]

Sanjeeb -

This is a bit confusing. The e-mail you are quoting is from 02/2009... over
4.5 years ago. We don't even use autoconf / automake anymore.

What is the problem you are having?

Cheers,
Ben


On Mon, Aug 19, 2013 at 9:15 PM, sanjeeb wrote:

> Johnathan Corgan  corganenterprises.com> writes:
>
> >
> > On Thu, Feb 12, 2009 at 2:03 AM, Emil Molin  gmail.com>
> wrote:
> >
> > >> > after doing ./bootstrap and then ./configure
> > >> >
> > >> > make gives the following message:
> > >> >
> > >> > libtool: Version mismatch error.  This is libtool 2.2.6, but the
> > >> > libtool: definition of this LT_INIT comes from an older release.
> > >> > libtool: You should recreate aclocal.m4 with macros from libtool
> 2.2.6
> > >> > libtool: and run autoconf again.
> > >> > make[3]: *** [howto.lo] Error 63
> > >> > make[2]: *** [check] Error 2
> > >> > make[1]: *** [check-recursive] Error 1
> >
> > Can you give us the details on your OS, GNU Radio version, installed
> > libtool and automake verions?
> >
> > Thanks.
> >
> > Johnathan
> >
> Hello There,
>
> After ./bootstrap and ./ configure when I run make, I am having the
> following error in my ubantu 11.10 OS.
> Need help
>
> make[3]: *** [usrp_rx_cfile] Error 1
> make[3]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gr-usrp/apps'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gr-usrp'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio'
> make: *** [all] Error 2
>
>
>
>
> ___
> 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] [USRP-users] AssertionError: udp_zero_copy

[Sam mite]

Hi Ben,

On Wed, Aug 21, 2013 at 5:37 AM, Ben Hilburn  wrote:

> Sam -
>
> Whoa. That is bizarre. And unprecedented.
>
>1. Does this happen consistently?
>
> No, it happened two times in months. But, I am concerned with this now.

>
>1. What command are you running that generates this issue?
>
>  curr_time = uhd_usrp_sink_0.get_time_now(). Almost 5-10 times in one
second. Just for your information, I have a GPSDO kit installed too.


>
>1. Can you provide us with more information regarding your network
>controller?
>
>  $ lspci | egrep -i --color 'network|ethernet'
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
Connection (rev 05)

>
>1. How did you install UHD?
>
> I installed gnuradio and UHD using the build script

wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
./build-gnuradio && ./build-gnuradio

Cheers,
> Ben
>
> Please let me know if you require any further information to solve the
issue.

Regards,
Sam

>
> 
> Ettus Research, LLC    |   USRP
>
>
> On Mon, Aug 19, 2013 at 9:15 PM, Sam mite  wrote:
>
>> Hi list,
>>
>>  I am using gnuradio 3.6.3rc0 and uhd UHD_003.005.000-26-gb65a3924. USRP
>> is N210 with a GPSDO. GNU C++ version 4.6.3. Linux Ubuntu 12.04 LTS.  I am
>> getting following error:
>>
>> terminate called after throwing an instance of 'uhd::assertion_error'
>>   what():  AssertionError: ::send(_sock_fd, (const char *)_mem, size(),
>> 0) == ssize_t(size())
>>   in virtual void udp_zero_copy_asio_msb::release()
>>   at /home/sam/uhd/host/lib/transport/udp_zero_copy.cpp:115
>>
>> What does that mean? What is the fix?
>>
>> --
>>
>> Best Regards,
>>
>> Sam
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Make fails and gives the following

[sanjeeb]

Hi there, 

after ./bootstrap and ./configure when i run make
i get the following: 
libtool: Version mismatch error.  This is libtool 2.4.2
Debian-2.4.2-1ubuntu1, but the
libtool: definition of this LT_INIT comes from libtool 2.2.6b.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2
Debian-2.4.2-1ubuntu1
libtool: and run autoconf again.
make[6]: *** [pmt.lo] Error 63
make[6]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gruel/src/lib/pmt'
make[5]: *** [all] Error 2
make[5]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gruel/src/lib/pmt'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gruel/src/lib'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gruel/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gruel'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio'
make: *** [all] Error 2


Need help






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