Re: [Discuss-gnuradio] Re g tunnel.py

[sumitstop]

This happened with me too several times. 

I can suggest you following :

1. See the frequency offset between the two usrp

2. When you do sudo ifconfig gr0  , see which port has been created
.. sometimes it allot gr1 , gr2 instead of gr0. In my case that created some
problem which got solved when I restarted the system.

lee me know the situation after you are done with this 



nadya hassan wrote:
> 
> hi sumitstop,
> i am trying to ping using the same IP address (192.168.200.1 &
> 192.168.200.2) put it doesn't work with me :( and give me distnation
> unreachable ,can you help me or there is any suggestions to solve this
> problem or can you kindly list step by step  (with all used versions of
> gnuradio and ubuntu...etc) or how you do ping may i have a problem in my
> steps ?
> hope you help me 
> thanks in advance
>  
> 
> sumitstop wrote:
>> 
>> Hi all,
>> 
>> Can I use tunnel.py for more than 2 systems. Right now I am able to ping
>> between two systems ( 192.168.200.1  & 192.168.200.2). But when I run the
>> same program in the third system (192.168.200.3) it says destination host
>> unreachable after pinging.
>> 
>> ** USRP-1
>> Ubuntu 10.04
>> gnuradio 3.5.2
>> 
> 
> 


-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/Reg-tunnel.py-tp33568806p34105979.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

[Discuss-gnuradio] how to get a range of receiving SNRs

[azalea au]

Dear all,

I'm transmitting some data between two usrps (N210) and using OFDM blocks in 
GRC in the two computers. My experiment is getting BER in a range of SNRs, like 
0~20dB. So I need to set the usrps to get a range of SNRs. However, fixing one 
usrp and moving the other along a line from 0m to 3m doesn't change SNR much.  
I also tried tuning antenna gain of UHD source in GRC and found that higher the 
receiving gain, lower the SNR, why? Also, the highest SNR I ever got is around 
9dB using 16qam.

However, could anyone tell me how to set or locate usrps to get a series of 
gradually increasing SNRs from 0~20dB? Thank you very munch! Any help is 
appreciated.

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

Re: [Discuss-gnuradio] Ubuntu 11.10 GNURadio Companion not installing help

[Alex Dekker]

On Monday 02 Jul 2012 23:19:24 Jared Harvey wrote:

> /home/jharvey/.local/lib/python2.7/site-packages/numpy/core/multiarray.so:
> wrong ELF class: ELFCLASS32

Mixture of 32 and 64 bit packages, by any chance?

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

[Discuss-gnuradio] OFDM Questions

[Amr Youssef]

Hi all , i have some questions  :

In OFDM Modulator Block , in Mapper Sub-block , in path of :
./lib/digital_ofdm_mapper_bcv.
cc

 1- I saw the following comment inside the code :  " Eventually, we will
get rid of the occupied_carriers concept. " , the question how you get rid
of the occupied carriers concept in the code and why ? . as i see the code
depends strongly on this concept .

2- Why the concept of occupied carriers is used  and why filling only part
of FFT size not all of it  ?

3-Inside the code ,  string carriers = "FE7F" .  I have two questions here
, the first is ,  when converting to bits : 11100111 , why there is
two zeros at DC instead of one zero only ?
The second question is , you started with "FE7F" .  Why  didn't  you start
with "E7"  and then pad F's from both sides  (looping) as  you did later !?

4- Also , for the following segment of the code : diff =
(d_occupied_carriers - 4*carriers.length())  .  Why you are multiplying by
four instead of eight when converting from Character Domain to Bit Domain ?
or you deal with them as HEX only ?


5- What is the maximum packet size ?

6- What is the difference between the word "coming message" and " packet" .
Are they the same thing ?  or Does one message contain more than one packet
?

Another Question in OFDM_frame_sink , what is the meaning of the parameter
d_dfe ?

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

Re: [Discuss-gnuradio] Ubuntu 11.10 GNURadio Companion not installing help

[Jared Harvey]

Hello Alex,

>> /home/jharvey/.local/lib/python2.7/site-packages/numpy/core/multiarray.so:
>> wrong ELF class: ELFCLASS32

AD> Mixture  of  32  and  64  bit packages, by any
AD> chance?

Not   likely,   but  perhaps.  The  packages  were
installed via package manager, or the the GNURadio
build  script.  So I assume it all 64 bit, however
if  I  knew how to check, I'd check. Do you have a
suggested  way  to check? I see from Synaptic that
it doesn't seem to specify 32 or 64.

Best regards.

.. ..-. / -.-- --- ..- / .-. . .- -.. /  -  .. ...   
.-.. . - ... /  .- ...- . / .- / -... . . .-. 

 Jared Harvey   Operator KB1GTT

e-mail m...@jaredharvey.com
Web page http://jaredharvey.com


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

Re: [Discuss-gnuradio] Ubuntu 11.10 GNURadio Companion not installing help

[Alex DEKKER]

On 03/07/12 20:34, Jared Harvey wrote:

Hello Alex,


/home/jharvey/.local/lib/python2.7/site-packages/numpy/core/multiarray.so:
wrong ELF class: ELFCLASS32

AD>  Mixture  of  32  and  64  bit packages, by any
AD>  chance?

Not   likely,   but  perhaps.  The  packages  were
installed via package manager, or the the GNURadio
build  script.  So I assume it all 64 bit, however
if  I  knew how to check, I'd check. Do you have a
suggested  way  to check? I see from Synaptic that
it doesn't seem to specify 32 or 64.

Architecture: line in the output of apt-cache show packagename, or is 
it? I can only find one i1386 package on my 64bit system, and the arch 
is listed as AMD64! 'dpkg -l | grep i386' should show up 32-on-64 packages.


Just noticed that the problem library is in ~/.local/. I've never seen 
that before, it seems to imply that you've got numpy installed in your 
home directory. Is that right? You could try moving ~/.local/lib/ to 
~/.local/lib-ignoreme/ and see if that fixes it. Might break a whole 
load of other stuff in the process too, of course.


alexd

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

[Discuss-gnuradio] building gnuradio - those annoying swig doc errors

[Josh Blum]

Hey list,

Ever build gnuradio with a lot of -j* and catch some error like "swig
doc generation failed, retrying..."? I believe this is a dependency
specification issue with the build system. Well, I think that I have
fixed it...

For those interested, give my josh_build_work branch a try
branch is josh_build_work on git://gnuradio.org/jblum.git
http://gnuradio.org/cgit/jblum.git/log/?h=josh_build_work

Let me know if the problem goes away for you too.
Feedback on this will be very helpful. Thanks!

-josh

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

Re: [Discuss-gnuradio] Questions

[Tom Rondeau]

On Wed, Jun 27, 2012 at 3:36 PM, Amr Youssef
 wrote:
> Hi all , i have some questions  :
>
> In OFDM Modulator Block , in Mapper Sub-block , in path of :
> ./lib/digital_ofdm_mapper_bcv.cc
>
>  1- I saw the following comment inside the code :  " Eventually, we will get
> rid of the occupied_carriers concept. " , the question how you get rid of
> the occupied carriers concept in the code and why ? . as i see the code
> depends strongly on this concept .

That most likely referred to using some kind of a carrier map to
specify which carriers are used, which unused, and which are pilots.
The occupied_carriers is just a number that says all of these carriers
in the middle are used for data. Not very flexible.

> 2- Why the concept of occupied carriers is used  and why filling only part
> of FFT size not all of it  ?

This is very common in OFDM. The side carriers are unused to allow for
roll-off in the channel filters and because OFDM's sinc signals in
frequency have a slow rolloff in power in the adjacent channels.
Blocking off the edges makes sure the energy outside of the channel is
lower.

> 3-Inside the code ,  string carriers = "FE7F" .  I have two questions here ,
> the first is ,  when converting to bits : 11100111 , why there is
> two zeros at DC instead of one zero only ?
> The second question is , you started with "FE7F" .  Why  didn't  you start
> with "E7"  and then pad F's from both sides  (looping) as  you did later !?

The two zeros are used to make sure that there is nothing depending on
the center carriers. With just the middle one (and which one is the
middle one?), the DC offset was still too much. Also, with DC offset
correction filters, there's a bit of a bandwidth to it. Cutting out
the center 2 was the only way to handle these problems.

The F's are used to be more clear with what's going on. Also, makes it
easier to change in the future.

> 4- Also , for the following segment of the code : diff =
> (d_occupied_carriers - 4*carriers.length())  .  Why you are multiplying by
> four instead of eight when converting from Character Domain to Bit Domain ?
> or you deal with them as HEX only ?

I really don't remember.


> 4- How many OFDM Symbols exist in one packet ?

Depends on the how many bits can fit into a symbol and how long the packet is.

> 5- What is the maximum packet size ?

I think it's capped at 1500 bytes. But because we only do freq, phase,
and timing correction with the preamble, you'll lose sync if your
packets are too long. We don't have any tracking algorithms
implemented to keep track of changes there.


> 6- What is the difference between coming message and the packet . Are they
> the same thing ?  or Does one message contain more than one packet ?
>
> Thanks in-advance
> Amr ,

The message can contain more than 1 packet, yes.

Tom

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

Re: [Discuss-gnuradio] Wait for another thread to finish in the top block?

[Tom Rondeau]

On Thu, Jun 21, 2012 at 11:00 PM, Dekst  wrote:
> Hi, All,
>
> For OFDM demodulation, in gnuradio/gr-digital/python/ofdm.py,  a
> _queue_watcher_thread is defined. It returns whether a packet is received
> correctly, what's the sequence number, and so on.
> I'm using gnuradio/gr-digital/examples/ofdm/benchmark_rx.py to decode
> samples saved by uhd/host/rx_samples_to_file.
> Thoses samples are processed by C++ modules and organized into packets
> enqueued in rcvd_pktq, waiting for _queue_watcher_thread to retreive them.
> I found that sometimes the benchmark_rx.py terminates before the rcvd_pktq
> is empty, that is, the _queue_watcher_thread hasn't finished all packets in
> the rcvd_pktq but the main program is terminated. Maybe all samples in the
> file have been processed by C++ modules and thus the main program
> terminates.
> How can I make the main program wait for the _queue_watcher_thread??? Make
> sure all packets in the queue are processed.
>
> Thanks a lot!
>
> Pei


You normally "join" a thread to wait for it to end. You might be able
to explicitly call a join on the watcher thread that would allow it to
continue. The problem there is that you now need to figure out a way
to tell that thread that it is done processing.

Tom

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

[Discuss-gnuradio] [USRP-users] Gigabit Ethernet card for USRP2

[Eduardo Lloret Fuentes]

Hello all,

I would like to ask you if you know a Gibabit Ethernet card that really
works with USRP2. I have seen that exists a list (
http://gnuradio.org/redmine/projects/gnuradio/wiki/USRP2GigEReports ) but
unfortunately, I can only use PCMCIA connectors.

Any advice?

Thanks,

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

Re: [Discuss-gnuradio] UDP sources blocking flowgraph when network is disconnected

[Tom Rondeau]

On Thu, Jun 21, 2012 at 6:43 AM, Nigel Orr wrote:

>
>   I am working on a gnuradio application which takes feeds from other
> sources over Ethernet. There is a possibility that the source will be
> disconnected occasionally due to intermittent network failures, when
> that happens I'd like the audio to go silent, and come back when the
> source is reconnected. In short, I'd like it to behave like an analogue
> audio connection :-) UDP looks like the closest option to that, so
> that's what I've tried so far.
>
> I currently connect the UDP blocks with something like
> udp_in = gr.udp_source((gr.sizeof_float*1), "0.0.0.0", 1234, 1472, True,
> True)
> and then connect them into the flowgraph.
>
> I have tried various options (all 4!) of the Boolean settings for Wait
> for data and empty packet = EOF, but it doesn't seem to do what I need.
> At best (with the above settings), the flowgraph pauses when the UDP is
> disconnected, so all the local sources which are still connected buffer
> up, resulting in long delays when the UDP comes back.
>
> Is it possible to get 'analogue-like' performance from a network socket
> connection, if so how should I do that within gnuradio? Is there
> something clever I can do with Throttle or Valve or something which will
> decouple loss of a UDP audio stream from the rest of the flowgraph?
>
> Thanks,
>
> Nigel
>

Hi Nigel,
Sorry for taking so long and then giving you this response. I really don't
have any good ideas to tell you for your problem. There's probably not a
good way to do it currently, so you might need to roll your own
implementation of the UDP source block that performs like you want it to.

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

Re: [Discuss-gnuradio] building gnuradio - those annoying swig doc errors

[Johnathan Corgan]

On Tue, Jul 3, 2012 at 2:11 PM, Josh Blum  wrote:


> Ever build gnuradio with a lot of -j* and catch some error like "swig
> doc generation failed, retrying..."? I believe this is a dependency
> specification issue with the build system. Well, I think that I have
> fixed it...
>
> For those interested, give my josh_build_work branch a try
> branch is josh_build_work on git://gnuradio.org/jblum.git
> http://gnuradio.org/cgit/jblum.git/log/?h=josh_build_work
>
> Let me know if the problem goes away for you too.
> Feedback on this will be very helpful. Thanks!
>

Awesome stuff.

I cherry-picked the relevant commits onto a test branch based off maint
instead of master.  There were a couple minor conflicts easily fixed.  So
far -j8 works fine, and I'm testing -j now.

This has been pushed to branch 'test-doc-fix-maint' on the main GNU Radio
repository, for easier testing.

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

[Discuss-gnuradio] How calibrate RFX900

[Julio Hector Aguilar Renteria]

Hi, All

How calibrate the RFX900 for working USRP2, sense spectrum.

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

Re: [Discuss-gnuradio] How calibrate RFX900

[Josh Blum]

On 07/03/2012 02:40 PM, Julio Hector Aguilar Renteria wrote:
> Hi, All
> 
> How calibrate the RFX900 for working USRP2, sense spectrum.
> 
> uhd_cal_rx_iq_balance
> uhd_cal_tx_dc_offset
> uhd_cal_tx_iq_balance
> 
> 

You can read more about the calibration utilities here:
http://files.ettus.com/uhd_docs/manual/html/calibration.html

-josh

> 
> ___
> 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] building gnuradio - those annoying swig doc errors

[Johnathan Corgan]

On Tue, Jul 3, 2012 at 2:35 PM, Johnathan Corgan <
jcor...@corganenterprises.com> wrote:


> I cherry-picked the relevant commits onto a test branch based off maint
> instead of master.  There were a couple minor conflicts easily fixed.  So
> far -j8 works fine, and I'm testing -j now.
>

There still seems to be an issue triggered when using 'make -j'. The end
result is that the SWIG generated _gnuradio_core_*.so files have no actual
code content, just overhead, and end up only a few kilobytes in length.
Then running make again causes the SWIG generated cxx files to get
compiled, but the output .so files are still broken (all the QA fails).

Notably, none of the original SWIG doc generation stuff is failing anymore,
so that appears to be fixed, but clearly there is more going on.  I've seen
the above issue in the past with -j8 and -j16 on rare occasions, so this
issue has been around awhile.

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

[Discuss-gnuradio] Error: timed out waiting for TX and/or RX LO to lock

[Julio Hector Aguilar Renteria]

Hi, all

help error uhd_cal_tx_iq_balance --verbose

root@usrp2:/usr/local/bin# uhd_cal_tx_iq_balance --verbose
linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.002-177-unstable


Creating the usrp device with: ...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Error: timed out waiting for TX and/or RX LO to lock
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building gnuradio - those annoying swig doc errors

[Josh Blum]

On 07/03/2012 03:14 PM, Johnathan Corgan wrote:
> On Tue, Jul 3, 2012 at 2:35 PM, Johnathan Corgan <
> jcor...@corganenterprises.com> wrote:
> 
> 
>> I cherry-picked the relevant commits onto a test branch based off maint
>> instead of master.  There were a couple minor conflicts easily fixed.  So
>> far -j8 works fine, and I'm testing -j now.
>>
> 
> There still seems to be an issue triggered when using 'make -j'. The end
> result is that the SWIG generated _gnuradio_core_*.so files have no actual
> code content, just overhead, and end up only a few kilobytes in length.
> Then running make again causes the SWIG generated cxx files to get
> compiled, but the output .so files are still broken (all the QA fails).
> 

So is this new, ie added by these swig fixes? I have never seen this one
before.

> Notably, none of the original SWIG doc generation stuff is failing anymore,
> so that appears to be fixed, but clearly there is more going on.  I've seen
> the above issue in the past with -j8 and -j16 on rare occasions, so this
> issue has been around awhile.
> 

Just to confirm. It is *not* failing anymore. We have forward progress
(or a little backward progress as well)?

-josh

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

Re: [Discuss-gnuradio] Error: timed out waiting for TX and/or RX LO to lock

[John Malsbury]

Julio,

50 ms seems like a lot of time to allow for a lock, but try changing:

boost::this_thread::sleep(boost::posix_time::milliseconds(50));

to:

boost::this_thread::sleep(boost::posix_time::milliseconds(500));

In the source file of uhd_cal_tx_balance.cpp.  Let us know if that 
doesn't fix things.


-John



On 07/03/2012 03:27 PM, Julio Hector Aguilar Renteria wrote:


Hi, all

help error uhd_cal_tx_iq_balance --verbose

root@usrp2:/usr/local/bin# uhd_cal_tx_iq_balance --verbose
linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.002-177-unstable


Creating the usrp device with: ...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Error: timed out waiting for TX and/or RX LO to lock


___
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] building gnuradio - those annoying swig doc errors

[Johnathan Corgan]

On Tue, Jul 3, 2012 at 3:31 PM, Josh Blum  wrote:


> So is this new, ie added by these swig fixes? I have never seen this one
> before.
>

I don't think the .so issue is caused by the swig fixes.  Doing 'make -j'
on master fails the same way.

But the swig doc issues that you were trying to fix do indeed appear to
have been fixed.

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

Re: [Discuss-gnuradio] Remove USRP filters.

[Andrew Davis]

>Are they supposed to be in 400ms long packets?

Well that is supposed to be the maximum time a FHSS is allowed to
dwell in a channel according to the FCC, so it makes sense.

>Do they use a slow FSK modulation?

According to the FCC test report is uses a CC1020 chip modem which in
its data sheet says it can use slow FSK.

> What daughterboard are you using?  Have you modified the FPGA?

WBX and nope.

> First there is a short burst I not sure about

I was thinking about using a 400ms hop time and I realized how long it
would take for synchronization to occur listening to any one
frequency, what I would do is use a quick burst on a listening
frequency to sync. That may be what that is?

> I read the time ruler in reverse.

Yeah it's strange, the waterfall is flowing up away from the
spectrogram ( as is should ), baudline is counting ms back in time
form the present ( I'm scrolling back in time to find the burst ).

I think I now need to find another old gameboy so I can start a
conversation between them to see if messages are plain text. I am
currently just probably getting the one announcing its presence
signal.

Thanks
~Andrew

On Mon, Jul 2, 2012 at 9:36 PM, Michael Ossmann  wrote:
> On Mon, Jul 02, 2012 at 08:27:01PM -0400, Andrew Davis wrote:
>>
>> Really cool presentation!  Thanks for the info. Now i'm running into
>> another problem, I sample at about 4MSPS for a bit and try to capture
>> the signal as it passes though my window, but I never seem to get it,
>> just a huge mess of noise, aliasing and ghosts.
>> http://i.imgur.com/w3oBP.jpg
>
> That actually doesn't look so bad to me.  Do you know anything about the
> transmissions from your target device?  Are they supposed to be in 400
> ms long packets?  Do they use a slow FSK modulation?  Are packets
> supposed to happen as often as every 600 ms?  If you don't know that
> stuff, try looking up the FCC test report for the device.
>
> You can ignore all the spurs and images in the frequency domain that are
> 20 dB or more below the loudest thing going on at any particular moment.
> You'll see stuff like that with a USRP, much more so when you are
> intentionally aliasing.
>
> What daughterboard are you using?  Have you modified the FPGA?
>
>> I really can tell what i'm looking at, doesn't look like FHSS to me.
>
> It does to me.  First there is a short burst I not sure about, but then
> there are two events of the same duration, the first was received at a
> lower power than the second.  The first event could be a packet outside
> your band that you are not receiving properly, and the second is within
> your band.  Oh, sorry.  I read the time ruler in reverse.
>
>> I did capture what I think is a sync preamble followed by FSK (
>> http://i.imgur.com/EpMim.jpg )
>
> That looks beautiful!  Except I think it is the time ruler itself that
> is reversed, not my reading of it.  The image is much lower power than
> the main signal.  Just ignore it.  That packet is decodable by eyeball
> in the spectrogram, which is kind of a rare treat.
>
> Throw that thing into grc and decode it!  :-)
>
> If you need help, post the raw file shown in EpMim.jpg somewhere.

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

Re: [Discuss-gnuradio] building gnuradio - those annoying swig doc errors

[Johnathan Corgan]

On Tue, Jul 3, 2012 at 3:42 PM, Johnathan Corgan <
jcor...@corganenterprises.com> wrote:

> On Tue, Jul 3, 2012 at 3:31 PM, Josh Blum  wrote:
>
> I don't think the .so issue is caused by the swig fixes.  Doing 'make -j'
> on master fails the same way.
>
> But the swig doc issues that you were trying to fix do indeed appear to
> have been fixed.
>

Both the above issues have been fixed and pushed to maint->master->next.

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

Re: [Discuss-gnuradio] [USRP-users] Gigabit Ethernet card for USRP2

[Eduardo Lloret Fuentes]

Hello,

Sorry, I forgot to say that for this special occasion I need to use the raw
ethernet driver...

Any idea?

Thanks for your answer!

Eduardo.

2012/7/3 Ben Hilburn 

> I have updated the page to reflect the current state of UHD support and
> GigE cards.
>
> Cheers,
> Ben
> 
> Ben Hilburn  @ Ettus Research, LLC
>  |   USRP 
>
>
>
> On Tue, Jul 3, 2012 at 2:19 PM, John Malsbury wrote:
>
>> **
>> The selectivity of GigE cards with the USRP2 was pre-UHD(raw ethernet).
>> If you're using UHD, basically any GigE card should work fine.
>>
>> Tom,
>>
>> Can you update this page to mention that all GigE cards should work
>> reasonably well with UHD?
>>
>> -John
>>
>>
>>
>>
>> On 07/03/2012 02:14 PM, Eduardo Lloret Fuentes wrote:
>>
>> Hello all,
>>
>>  I would like to ask you if you know a Gibabit Ethernet card that really
>> works with USRP2. I have seen that exists a list (
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/USRP2GigEReports )
>> but unfortunately, I can only use PCMCIA connectors.
>>
>>  Any advice?
>>
>>  Thanks,
>>
>>  Eduardo.
>>
>>
>> ___
>> USRP-users mailing 
>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> ___
> 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