Send USRP-users mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

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


Today's Topics:

   1. Re: USRP B2xx Transport Control for low-bandwidth signals
      (Balint Seeber)
   2. rx_samples_to_file and a fifo (alejandro kilei)
   3. Re: rx_samples_to_file and a fifo (Robert Kossler)
   4. Error: Connection refused (Hossein Soleymani)
   5. Setting RX/TX rates to 100Msps for N210 (Adrian Martinez Gomez)
   6. Re: Error: Connection refused (Mike Jameson)


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

Message: 1
Date: Thu, 12 Jun 2014 09:48:09 -0700
From: Balint Seeber <[email protected]>
To: Jacob Gilbert <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B2xx Transport Control for
        low-bandwidth   signals
Message-ID:
        <CAPcb_2rLAgyhZgfgq12hikdnzSud+7KvJFyONehCG4tTJC0=w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Jacob,

You might be experiencing the 'two clock' problem, since your audio source
and the B210 are driven by different crystals (I have seen this before
myself).

To test this, please have a look at Lab 5 here:
http://files.ettus.com/tutorials/labs/ (I resample to 1.1 x the USRP sample
rate of 250ksps).

There are more notes on this here:
http://files.ettus.com/tutorials/labs/html/img88.html (or the PDF in the
directory linked above).

Let us know what happens when you make that change!

Kind regards,
Balint


On Fri, Jun 6, 2014 at 6:33 AM, Jacob Gilbert via USRP-users <
[email protected]> wrote:

> Hello,
>
> I am experiencing frequent underflows with the B210 and ran into a few
> questions regarding UHD USB flow control.
>
> I am using a rate limited source (Audio Source) and generating a
> low-bandwidth signal (256kS/s) and sending to the USRP. I notice a large
> number of underflows (and LED flickering) on the B210 using this
> configuration. If I interpolate and use a larger sample rate (1024kS/s) the
> problem is greatly reduced. At 4096kS/s it is effectively gone. This
> unfortunately doesn?t work well for what I need (the host cannot keep up
> with this rate over USB and the necessary filtering to produce a suitably
> clean interpolated signal) so I am hoping you can give me some help here.
>
> As another data point the application works fine at 256kS/s on the B100 on
> a non-disadvantaged platform but exhibits the same behavior using the B210.
>
> Based on the UHD Transport Application Notes Ettus page, it looks like
> there are 4 parameters that can be tweaked to modify behavior of the USB
> transport mechanism. These do not appear to have much of an impact, if any
> but I don?t quite understand which set I should modify for transmit
> applications. I also noticed on the Ettus page regarding latency, there is
> a note that the B100 has a ?flush timer? that also impacts the USB latency.
>
> 1. If I am attempting to transmit low bandwidth signals, which parameters
> should be changed?
>
> 2. Does the flush timer note impact the B2xx and can this be set from the
> gr-uhd interface (and if so, how)?
>
> 3. Am I overlooking something?
>
>
> Thanks for the help,
>
> Jacob
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140612/9c41ae8b/attachment-0001.html>

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

Message: 2
Date: Thu, 12 Jun 2014 11:45:25 -0600
From: alejandro kilei <[email protected]>
To: [email protected]
Subject: [USRP-users] rx_samples_to_file and a fifo
Message-ID:
        <can6oax0u4kok8zurohrukithscrsezm-clgmaqoej+_z17e...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I need to modify the rx_samples_to_file example that came with UHD so that
it continuously writes to memory (and eventually read from memory).
Currently I'm trying to integrate the fifo.c example from xillybus which is
supposed to be good for a continuous high rate I/O. Does anyone have
suggestions of how I could either edit the rx_samples_to_file code to write
to memory or how to integrate the fifo.c program?
Thanks for the help. You are a lot of help.
Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140612/11e5f4d7/attachment-0001.html>

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

Message: 3
Date: Thu, 12 Jun 2014 14:02:27 -0400
From: Robert Kossler <[email protected]>
To: alejandro kilei <[email protected]>,
        "[email protected]"    <[email protected]>
Subject: Re: [USRP-users] rx_samples_to_file and a fifo
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="utf-8"

I have not tried this modification that you discussed, but wanted to mention 
that I have setup a Ubuntu ?ram drive? such that the file i/o operations are 
writing to RAM instead of hard drive/ssd.  By doing so, I was able to achieve 
full I/O rates (e.g., 2 channels at 100 Ms/s for X310) to this RAM file.

Rob

From: USRP-users [mailto:[email protected]] On Behalf Of 
alejandro kilei via USRP-users
Sent: Thursday, June 12, 2014 1:45 PM
To: [email protected]
Subject: [USRP-users] rx_samples_to_file and a fifo

I need to modify the rx_samples_to_file example that came with UHD so that it 
continuously writes to memory (and eventually read from memory). Currently I'm 
trying to integrate the fifo.c example from xillybus which is supposed to be 
good for a continuous high rate I/O. Does anyone have suggestions of how I 
could either edit the rx_samples_to_file code to write to memory or how to 
integrate the fifo.c program?
Thanks for the help. You are a lot of help.
Alejandro

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140612/3f3ee6b7/attachment-0001.html>

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

Message: 4
Date: Fri, 13 Jun 2014 10:15:32 +0200
From: Hossein Soleymani <[email protected]>
To: "[email protected]" <[email protected]>, Marcus
        M?ller <[email protected]>,      Ettus Research Support
        <[email protected]>
Subject: [USRP-users] Error: Connection refused
Message-ID:
        <cab8nzszqddvom1aqvwrqezftsh7t8bpha1hk1pgegmgzkn2...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi





*I have problem as following.Is there any idea to solve my problem?if I run
gnuradio-companion in terminal. I give:*

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.007.000-0-unknown

<<< Welcome to GNU Radio Companion 3.7.3 >>>

Showing: ""



*but when I wrote in terminal  uhd_usrp_probe :*

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.007.000-0-unknown

Error: Connection refused



*also if I wrote  uhd_fft I received:*


linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.007.000-0-unknown

Connection refused

*when I wrote in terminal uhd_fft -a type=usrp2 -f 2410M -s 2M and It shows
the capturing signal in Gnu radio companion, however I give this complain
in terminal*

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.007.000-0-unknown

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

UHD Warning:
    Unable to set the thread priority. Performance may be negatively
affected.
    Please see the general application notes in the manual for instructions.
    EnvironmentError: OSError: error in pthread_setschedparam
Using Volk machine: sse4_2_64_orc
/home/acts/.gnuradio/prefs/vmcircbuf_default_factory: Permission denied
vmcircbuf_createfilemapping: createfilemapping is not available
/home/acts/.gnuradio/prefs/vmcircbuf_default_factory: Permission denied

*When I my program in GNU radio companion , It is complain like this:*

<<< Welcome to GNU Radio Companion 3.7.3 >>>

Loading: "/media/HD-PCTU3/USRP 1/ED.grc"
>>> Done

Showing: "/media/HD-PCTU3/USRP 1/ED.grc"

Generating: "/media/HD-PCTU3/USRP 1/top_block.py"

Generating: "/media/HD-PCTU3/USRP 1/top_block.py"

Executing: "/media/HD-PCTU3/USRP 1/top_block.py"

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.007.000-0-unknown

Traceback (most recent call last):
  File "/media/HD-PCTU3/USRP 1/top_block.py", line 113, in <module>
    tb = top_block()
  File "/media/HD-PCTU3/USRP 1/top_block.py", line 57, in __init__
    channels=range(1),
  File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
122, in constructor_interceptor
    return old_constructor(*args)
  File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
1745, in make
    return _uhd_swig.usrp_source_make(*args)
RuntimeError: Connection refused



Best Regard

Hossein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140613/ea223589/attachment-0001.html>

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

Message: 5
Date: Fri, 13 Jun 2014 14:20:26 +0200
From: Adrian Martinez Gomez <[email protected]>
To: [email protected]
Subject: [USRP-users] Setting RX/TX rates to 100Msps for N210
Message-ID:
        <CABEfXYBLVvi0K-KgvQ9OahZVi_N+G=e5noR_G04+RT8zfU=f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear USRP users,

my setup is a USRP N210 with WBX daughterboard. I am using UHD 003.007.000
version.

I have been recently implementing a FPGA level 4 bit I/Q image (on the
/uhd/fpga/usrp2/custom directory).

Now, I want to be able to set 100Msps when RX and TX when I use
rx_samples_to_file or tx_samples_from_file, since with my FPGA
modifications I'd be able from the Ethernet bottleneck to achieve this.

The problem is UHD-related, as the multi_usrp.cpp [1] has a warning for the
function set_rx_gain() which sets the rate to 50Msps if the rate is bigger
than this.
I'm by not so good at C++, so any help would be nice

Which methods/functions/files should I modify to be able to record/replay
at 100Msps, overcoming this warning?
Any help or advice will be appreciated!

Kind regards,
Adrian.

P.S. I became from mbr0wn the advice to follow the property tree (using
uhd_usrp_probe --tree) and find the rate property. I don't know how this
helps, or what consequences it has, but running uhd_usrp_probe --tree |
grep rate shows [2].



[1]
https://github.com/EttusResearch/uhd/blob/9ed3becc1b02628a24eb07e6d8cd70b42638c5f3/host/lib/usrp/multi_usrp.cpp
[2] http://pastebin.com/CzGj9Yg0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140613/2e7d7944/attachment-0001.html>

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

Message: 6
Date: Fri, 13 Jun 2014 13:29:04 +0100
From: Mike Jameson <[email protected]>
To: Hossein Soleymani <[email protected]>
Cc: "[email protected]" <[email protected]>,  Ettus
        Research Support <[email protected]>
Subject: Re: [USRP-users] Error: Connection refused
Message-ID:
        <cajcjmiqczckvgj_ko+a_hy2ev5+bq659swvxg-zgd9xidvs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I notice is that '/media/HD-PCTU3/USRP 1/' has a space in it.  In order to
rule out an incorrect path parsing issue, rename the folder from 'USRP 1'
to 'USRP_1' and see if that fixes things.

If not, make sure the '/home/acts/.gnuradio' directory and
'/media/HD-PCTU3' directories have full permissions for your usename 'acts':

chown -R acts:acts '/home/acts/.gnuradio'
chown -R acts:acts '/media/HD-PCTU3'

Finally, to rule out a root permissions issue you could run 'sudo
gnuradio-companion' and see if it fixes things.  If the first time you ran
'gnuradio-companion' was with root permissions then the initial config
files may have been setup with unwanted root permissions.

Mike

--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: [email protected]
Web: http://ettus.com


On Fri, Jun 13, 2014 at 9:15 AM, Hossein Soleymani via USRP-users <
[email protected]> wrote:

>
> Hi
>
>
>
>
>
> *I have problem as following.Is there any idea to solve my problem?if I
> run gnuradio-companion in terminal. I give:*
>
> linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.007.000-0-unknown
>
> <<< Welcome to GNU Radio Companion 3.7.3 >>>
>
> Showing: ""
>
>
>
> *but when I wrote in terminal  uhd_usrp_probe :*
>
> linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.007.000-0-unknown
>
> Error: Connection refused
>
>
>
> *also if I wrote  uhd_fft I received:*
>
>
> linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.007.000-0-unknown
>
> Connection refused
>
> *when I wrote in terminal uhd_fft -a type=usrp2 -f 2410M -s 2M and It
> shows the capturing signal in Gnu radio companion, however I give this
> complain in terminal*
>
> linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.007.000-0-unknown
>
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
>     Unable to set the thread priority. Performance may be negatively
> affected.
>     Please see the general application notes in the manual for
> instructions.
>     EnvironmentError: OSError: error in pthread_setschedparam
> Using Volk machine: sse4_2_64_orc
> /home/acts/.gnuradio/prefs/vmcircbuf_default_factory: Permission denied
> vmcircbuf_createfilemapping: createfilemapping is not available
> /home/acts/.gnuradio/prefs/vmcircbuf_default_factory: Permission denied
>
> *When I my program in GNU radio companion , It is complain like this:*
>
> <<< Welcome to GNU Radio Companion 3.7.3 >>>
>
> Loading: "/media/HD-PCTU3/USRP 1/ED.grc"
> >>> Done
>
> Showing: "/media/HD-PCTU3/USRP 1/ED.grc"
>
> Generating: "/media/HD-PCTU3/USRP 1/top_block.py"
>
> Generating: "/media/HD-PCTU3/USRP 1/top_block.py"
>
> Executing: "/media/HD-PCTU3/USRP 1/top_block.py"
>
> linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.007.000-0-unknown
>
> Traceback (most recent call last):
>   File "/media/HD-PCTU3/USRP 1/top_block.py", line 113, in <module>
>     tb = top_block()
>   File "/media/HD-PCTU3/USRP 1/top_block.py", line 57, in __init__
>     channels=range(1),
>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
> 122, in constructor_interceptor
>     return old_constructor(*args)
>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 1745, in make
>     return _uhd_swig.usrp_source_make(*args)
> RuntimeError: Connection refused
>
>
>
> Best Regard
>
> Hossein
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140613/cb35699d/attachment-0001.html>

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

Subject: Digest Footer

_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

End of USRP-users Digest, Vol 46, Issue 13
******************************************

Reply via email to