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. Is it possible to set the clock_source directly via the
--args options ([email protected])
2. Re: Is it possible to set the clock_source directly via the
--args options (Martin Braun)
3. B210 custom UHD chain module ( for example FIR filter or WBFM
demod ) in verrilog example? (Ben Biles)
4. Receiving problem with USRP N210 (Su Li)
5. Re: Receiving problem with USRP N210 (Marcus M?ller)
6. Re: Receiving problem with USRP N210 (Marcus M?ller)
7. Re: B100 + WBX Aliasing (Matt Ettus)
8. Re: 3.8.0 build issues on centos 6 (Stan Vitebsky)
9. Re: 3.8.0 build issues on centos 6 (Neel Pandeya)
10. Re: 3.8.0 build issues on centos 6 (Stan Vitebsky)
11. Re: 3.8.0 build issues on centos 6 (Marcus M?ller)
12. Re: B100 + WBX Aliasing (Andre Puschmann)
13. Re: USRP-users Digest, Vol 50, Issue 7 (gsmandvoip)
14. Boost Requirements (Was: 3.8.0 build issues on centos 6)
(Martin Braun)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 Oct 2014 16:14:09 +0000
From: <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Is it possible to set the clock_source directly
via the --args options
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello,
Quick question: is it possible to directly set the clock source via the device
arguments (and without having to call set_clock_source afterwards)? Ideally, I
would like to be able to do (pseudo-code):
uhd.usrp_source (device_addr='addr=192.168.10.2,clock_source=external',...)
I know I can pass master_clock_rate for instance.
Thanks
Ruben
------------------------------
Message: 2
Date: Wed, 15 Oct 2014 18:18:18 +0200
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Is it possible to set the clock_source
directly via the --args options
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
No, this is not possible.
M
On 10/15/2014 06:14 PM, Ruben Merz via USRP-users wrote:
> Hello, Quick question: is it possible to directly set the clock
> source via the device arguments (and without having to call
> set_clock_source afterwards)? Ideally, I would like to be able to do
> (pseudo-code):
>
> uhd.usrp_source
> (device_addr='addr=192.168.10.2,clock_source=external',...)
>
> I know I can pass master_clock_rate for instance. Thanks Ruben
>
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Wed, 15 Oct 2014 23:44:39 +0900
From: Ben Biles <[email protected]>
To: [email protected]
Subject: [USRP-users] B210 custom UHD chain module ( for example FIR
filter or WBFM demod ) in verrilog example?
Message-ID:
<CAFJFSVjE_v_g_zgB7yw2T=2CQ8eepN558KO39gegi2=fxea...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi, does anyone know if there are any example custom UHD chain modules
( for example FIR filter or WBFM demod ) in HDL anywhere for USRP B410
xilinx harware?
I would like to try and design a 10 channel WBFM ( 200khz bandwidth
per channel ) deviersity reciever in verilog in ISE.
I am assuming I would have to modify the USRP UHD and add verilog
modules of code in the two reciever chains in order to do this?
How do I learn more about this ?
What are the chances of fitting this into the remaining space on the
Xilinx FPGA on the B210? I believe it is slightly larger than
the FPGA on the B200, and obvoiusly I need 2 x RX for a diversity
capable reciever so B200 out anyway!
I will attempt to build it fist in GNUradio blocks but expect my i7
cpu will grind to halt !! what are the chances the FPGA will cope?
any ideas much welcome !
BEN
------------------------------
Message: 4
Date: Wed, 15 Oct 2014 17:02:16 +0200
From: Su Li <[email protected]>
To: [email protected]
Subject: [USRP-users] Receiving problem with USRP N210
Message-ID:
<CALJ4=odcav7dm2jy+pamazav65tqd9etzu9o80f9fegzqyj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have an USRP N210 with RFX2400 2.3-2.9GHZ RX/TX. I am trying to build a
communication link between Tmote sky wireless sensor node and USRP N210.
I use Tmote sky node to repeatedly broadcast messages on radio channel 26
with power level 31 (=0dBm). The code I use is the example code of Contiki
and I can receive this broadcast message by a receiver implemented by a
Tmote sky node.
However, I cannot receive the message on USRP N210. When I tried to check
the signal that the antenna received, I found nothing except the noise. In
GNU radio companion, I just used a UHD-USRP Source with frequency at
2.48GHz to get the signal from USRP and check them in a Scope sink. I
thought the power of the received signal would increase a lot when the
sensor node broadcast messages. But I did not see a large increment of the
amplitude of the signal. I also tried using trigger to catch the burst
spike, but I failed.
Anyone can give me some suggestions to fix this problem?
Thanks in advance.
Best regards,
Su
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141015/450ab870/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 15 Oct 2014 18:47:08 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Receiving problem with USRP N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello Su Li,
just a few general RF engineering debugging approaches:
* check your measurement set up. Is it the right antenna for this
frequency range, attached to the right port (believe me, I mistakenly
used the wrong port quite a couple of times), at the right receiving
bandwidth/sampling rate, with a feasible gain? If you don't risk
damaging your device, crank up the gain!
* A scope sink can impossibly show you fast bursty signals; if you know
your spectral shape (eg. it's GMSK with a 3dB bandwidth of 200kHz, or
it's 10MHz wide OFDM or so), use the waterfall sink. It will give you
some more long-time visual impression. Generally, any frequency domain
sink will most probably be better suited than using the scope sink.
* If that signal is spread-spectrum, you might not notice anything at
all looking at the spectrum or time domain signal at all. I don't know
this specific system, and I must admit it's a bit much asking for help
without giving us a few edge parameters to guess from ;)
* If you happen to know the pulse shape, implement a matched filter. You
seem to have a software sender -- so you should have the possibility to
get to know that shape. If the pulse shaping is in fact done by a FIR,
you could just take the taps and use their time-reversed conjugate as
the matched filter. That should give you some processing gain :)
Greetings,
Marcus
On 15.10.2014 17:02, Su Li via USRP-users wrote:
> Hi,
>
> I have an USRP N210 with RFX2400 2.3-2.9GHZ RX/TX. I am trying to build a
> communication link between Tmote sky wireless sensor node and USRP N210.
>
> I use Tmote sky node to repeatedly broadcast messages on radio channel 26
> with power level 31 (=0dBm). The code I use is the example code of Contiki
> and I can receive this broadcast message by a receiver implemented by a
> Tmote sky node.
>
> However, I cannot receive the message on USRP N210. When I tried to check
> the signal that the antenna received, I found nothing except the noise. In
> GNU radio companion, I just used a UHD-USRP Source with frequency at
> 2.48GHz to get the signal from USRP and check them in a Scope sink. I
> thought the power of the received signal would increase a lot when the
> sensor node broadcast messages. But I did not see a large increment of the
> amplitude of the signal. I also tried using trigger to catch the burst
> spike, but I failed.
>
> Anyone can give me some suggestions to fix this problem?
>
> Thanks in advance.
>
> Best regards,
> Su
>
>
>
> _______________________________________________
> 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/20141015/cfb2c691/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 15 Oct 2014 19:28:24 +0200
From: Marcus M?ller <[email protected]>
To: Su Li <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Receiving problem with USRP N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Glad things worked out for you!
On 15.10.2014 19:16, Su Li wrote:
> Hi Marcus,
>
> Thank you very much.
>
> Following your suggestions, I found the problem that I forgot to configure
> the antenna port. Since I only have one antenna, I thought it would
> automatically choose that one. But in fact, I still have to configure it as
> TX/RX.
>
> Best regards,
>
> Su
>
>
>
> 2014-10-15 18:47 GMT+02:00 Marcus M?ller <[email protected]>:
>
>> Hello Su Li,
>>
>> just a few general RF engineering debugging approaches:
>>
>> * check your measurement set up. Is it the right antenna for this
>> frequency range, attached to the right port (believe me, I mistakenly used
>> the wrong port quite a couple of times), at the right receiving
>> bandwidth/sampling rate, with a feasible gain? If you don't risk damaging
>> your device, crank up the gain!
>> * A scope sink can impossibly show you fast bursty signals; if you know
>> your spectral shape (eg. it's GMSK with a 3dB bandwidth of 200kHz, or it's
>> 10MHz wide OFDM or so), use the waterfall sink. It will give you some more
>> long-time visual impression. Generally, any frequency domain sink will most
>> probably be better suited than using the scope sink.
>> * If that signal is spread-spectrum, you might not notice anything at all
>> looking at the spectrum or time domain signal at all. I don't know this
>> specific system, and I must admit it's a bit much asking for help without
>> giving us a few edge parameters to guess from ;)
>> * If you happen to know the pulse shape, implement a matched filter. You
>> seem to have a software sender -- so you should have the possibility to get
>> to know that shape. If the pulse shaping is in fact done by a FIR, you
>> could just take the taps and use their time-reversed conjugate as the
>> matched filter. That should give you some processing gain :)
>>
>> Greetings,
>> Marcus
>>
>>
>> On 15.10.2014 17:02, Su Li via USRP-users wrote:
>>
>> Hi,
>>
>> I have an USRP N210 with RFX2400 2.3-2.9GHZ RX/TX. I am trying to build a
>> communication link between Tmote sky wireless sensor node and USRP N210.
>>
>> I use Tmote sky node to repeatedly broadcast messages on radio channel 26
>> with power level 31 (=0dBm). The code I use is the example code of Contiki
>> and I can receive this broadcast message by a receiver implemented by a
>> Tmote sky node.
>>
>> However, I cannot receive the message on USRP N210. When I tried to check
>> the signal that the antenna received, I found nothing except the noise. In
>> GNU radio companion, I just used a UHD-USRP Source with frequency at
>> 2.48GHz to get the signal from USRP and check them in a Scope sink. I
>> thought the power of the received signal would increase a lot when the
>> sensor node broadcast messages. But I did not see a large increment of the
>> amplitude of the signal. I also tried using trigger to catch the burst
>> spike, but I failed.
>>
>> Anyone can give me some suggestions to fix this problem?
>>
>> Thanks in advance.
>>
>> Best regards,
>> Su
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
------------------------------
Message: 7
Date: Wed, 15 Oct 2014 11:36:14 -0700
From: Matt Ettus <[email protected]>
To: Germano Capela <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B100 + WBX Aliasing
Message-ID:
<CAN=1kn8dUgpAiUmYavWFGwmr8ReLqVXv8ARp7kdA=x2d04i...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Quadrature mixers, as used in most SDRs including WBX are sensitive to
strong signals around the third harmonic of the local oscillator. 312 * 3
is 936 MHz, hence you see the GSM signal there. Analog filters or banks of
filters are necessary to get rid of signals like that if they are a problem
in your application.
Matt
On Sun, Oct 12, 2014 at 9:20 AM, Germano Capela via USRP-users <
[email protected]> wrote:
> Hi,
>
> When I run a simple spectrum measurement around 312MHz, I observe a
> powerful replica of the GSM900 downlink (arround 935 MHz) spectra. Is it
> possible that the anti-aliasing filters are not enough to prevent this
> effect?
>
> Regards,
>
> Germano
>
> _______________________________________________
> 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/20141015/e5529da2/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 15 Oct 2014 15:08:41 -0400
From: Stan Vitebsky <[email protected]>
To: Ben Hilburn <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 3.8.0 build issues on centos 6
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Ben,
Thank you for your reply.
Just FYI, after building and installing boost 1.55 on Centos 6, now uhd
3.8.0 builds ok
(the only issue that I still had to fix was to remove "d" from line 504
of /utils/latency/lib/Responder.cpp)
-Stan
On 10/14/14, 7:45 PM, Ben Hilburn wrote:
> Hi Stan -
>
> Thanks for letting us know! We'll look into it. It does sound like we
> may need to bump the minimum required version of Boost.
>
> Cheers,
> Ben
>
> On Tue, Oct 14, 2014 at 3:21 PM, Stan Vitebsky via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello,
>
> I have trouble building newly released uhd 3.8.0 on Centos 6
> (3.10.33 kernel).
> Previous release as well as the current maint branch are building
> successfully.
> The first error that fails the build is that
> boost/thread/shared_lock_guard.hpp file cannot be found in
> include/uhd/transport/nirio/niriok_proxy.h on line 26.
> I suppose this is because this file doesn't exist in boost 1.41,
> which is default for Centos 6.
> Does this mean that Centos 6 will no longer be supported by uhd?
>
> Thanks,
> -Stan
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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/20141015/ccf555f1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3305 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141015/ccf555f1/attachment-0001.p7s>
------------------------------
Message: 9
Date: Wed, 15 Oct 2014 12:42:32 -0700
From: Neel Pandeya <[email protected]>
To: Stan Vitebsky <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 3.8.0 build issues on centos 6
Message-ID:
<cacaxmv_fjruaciyugfthjxo_lspnwrvj0so00ub+rg_qrnk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Stan:
Thanks for your feedback. It's very useful information. Other than
upgrading Boost to version 1.55, was there anything else that you had to do
in order to get UHD 3.8.0 to build on CentOS 6? You're using the default
GCC 4.4.7?
I noticed that you had upgraded the kernel. You said you're running 3.10,
and the default for CentOS 6 is 2.6.32. Although this shouldn't affect
building 3.8.0, it might be important when running 3.8.0.
--Neel
On Wed, Oct 15, 2014 at 12:08 PM, Stan Vitebsky via USRP-users <
[email protected]> wrote:
> Hi Ben,
>
> Thank you for your reply.
> Just FYI, after building and installing boost 1.55 on Centos 6, now uhd
> 3.8.0 builds ok
> (the only issue that I still had to fix was to remove "d" from line 504 of
> /utils/latency/lib/Responder.cpp)
>
> -Stan
>
>
>
> On 10/14/14, 7:45 PM, Ben Hilburn wrote:
>
> Hi Stan -
>
> Thanks for letting us know! We'll look into it. It does sound like we
> may need to bump the minimum required version of Boost.
>
> Cheers,
> Ben
>
> On Tue, Oct 14, 2014 at 3:21 PM, Stan Vitebsky via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> I have trouble building newly released uhd 3.8.0 on Centos 6 (3.10.33
>> kernel).
>> Previous release as well as the current maint branch are building
>> successfully.
>> The first error that fails the build is that
>> boost/thread/shared_lock_guard.hpp file cannot be found in
>> include/uhd/transport/nirio/niriok_proxy.h on line 26.
>> I suppose this is because this file doesn't exist in boost 1.41, which is
>> default for Centos 6.
>> Does this mean that Centos 6 will no longer be supported by uhd?
>>
>> Thanks,
>> -Stan
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> _______________________________________________
> 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/20141015/21bd548e/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 15 Oct 2014 16:44:14 -0400
From: Stan Vitebsky <[email protected]>
To: Neel Pandeya <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 3.8.0 build issues on centos 6
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello Neel,
Yes, this is still using gcc 4.4.7, so I am getting a bunch of #pragma
related warnings that I assume is safe to ignore - I believe they should
go away with later versions of gcc.
I did not have to do anything special except building from source and
installing boost 1.55 and making the adjustment in Responder.cpp.
I did upgrade the kernel from 2.6.32 to 3.10.33 with RT_PREEMPT patch.
This was not related to any uhd 3.8.0 build issues though.
It was something I did some time ago, so I cannot say if there are any
additional issues you might encounter when working with the stock kernel.
I will update you if I notice anything else when I start running uhd 3.8.0
Best Regards,
-Stan
On 10/15/14, 3:42 PM, Neel Pandeya wrote:
> Hello Stan:
>
> Thanks for your feedback. It's very useful information. Other than
> upgrading Boost to version 1.55, was there anything else that you had
> to do in order to get UHD 3.8.0 to build on CentOS 6? You're using the
> default GCC 4.4.7?
>
> I noticed that you had upgraded the kernel. You said you're running
> 3.10, and the default for CentOS 6 is 2.6.32. Although this shouldn't
> affect building 3.8.0, it might be important when running 3.8.0.
>
> --Neel
>
>
> On Wed, Oct 15, 2014 at 12:08 PM, Stan Vitebsky via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Ben,
>
> Thank you for your reply.
> Just FYI, after building and installing boost 1.55 on Centos 6,
> now uhd 3.8.0 builds ok
> (the only issue that I still had to fix was to remove "d" from
> line 504 of /utils/latency/lib/Responder.cpp)
>
> -Stan
>
>
>
> On 10/14/14, 7:45 PM, Ben Hilburn wrote:
>> Hi Stan -
>>
>> Thanks for letting us know! We'll look into it. It does sound
>> like we may need to bump the minimum required version of Boost.
>>
>> Cheers,
>> Ben
>>
>> On Tue, Oct 14, 2014 at 3:21 PM, Stan Vitebsky via USRP-users
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> Hello,
>>
>> I have trouble building newly released uhd 3.8.0 on Centos 6
>> (3.10.33 kernel).
>> Previous release as well as the current maint branch are
>> building successfully.
>> The first error that fails the build is that
>> boost/thread/shared_lock_guard.hpp file cannot be found in
>> include/uhd/transport/nirio/niriok_proxy.h on line 26.
>> I suppose this is because this file doesn't exist in boost
>> 1.41, which is default for Centos 6.
>> Does this mean that Centos 6 will no longer be supported by uhd?
>>
>> Thanks,
>> -Stan
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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/20141015/7f75ee6d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3305 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141015/7f75ee6d/attachment-0001.p7s>
------------------------------
Message: 11
Date: Wed, 15 Oct 2014 23:00:52 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] 3.8.0 build issues on centos 6
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Short notes from my side, especially to document this for the people who
might search the mailing list later on:On 15.10.2014 22:44, Stan
Vitebsky via USRP-users wrote:
> Yes, this is still using gcc 4.4.7, so I am getting a bunch of #pragma
> related warnings that I assume is safe to ignore - I believe they
> should go away with later versions of gcc.
Yes, the "#pragma diagnostic push/pop" related warnings go away with gcc
4.6.5, as far as i can tell. They are safe to ignore from what I've seen.
> I did not have to do anything special except building from source and
> installing boost 1.55 and making the adjustment in Responder.cpp.
Responder.cpp is fixed in the current master since a few hours :)
> I did upgrade the kernel from 2.6.32 to 3.10.33 with RT_PREEMPT patch.
> This was not related to any uhd 3.8.0 build issues though.
> It was something I did some time ago, so I cannot say if there are any
> additional issues you might encounter when working with the stock kernel.
>
> I will update you if I notice anything else when I start running uhd
> 3.8.0
Thank you!
Greetings,
Marcus
------------------------------
Message: 12
Date: Thu, 16 Oct 2014 09:40:28 +0200
From: Andre Puschmann <[email protected]>
To: Matt Ettus <[email protected]>, Germano Capela
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B100 + WBX Aliasing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 10/15/2014 08:36 PM, Matt Ettus via USRP-users wrote:
>
> Quadrature mixers, as used in most SDRs including WBX are sensitive to
> strong signals around the third harmonic of the local oscillator. 312 *
> 3 is 936 MHz, hence you see the GSM signal there. Analog filters or
> banks of filters are necessary to get rid of signals like that if they
> are a problem in your application.
Germano,
I'd just like to add that, besides analog hardware that Matt has
mentioned, there is also DSP-based approaches for mitigating
non-linearities. Michael Grimm has developed an algorithm for that
during his Ph.D. This has also been implemented and practically verified
on the FPGA of the N210 with GSM signals [1]. Of course, both approaches
have there pros and cons but you may still find that helpful.
Thanks
Andre
[1] http://www.db-thueringen.de/servlets/DocumentServlet?id=24447&lang=en
>
> Matt
>
>
> On Sun, Oct 12, 2014 at 9:20 AM, Germano Capela via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi,
>
> When I run a simple spectrum measurement around 312MHz, I observe a
> powerful replica of the GSM900 downlink (arround 935 MHz) spectra.
> Is it possible that the anti-aliasing filters are not enough to
> prevent this effect?
>
> Regards,
>
> Germano
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 13
Date: Thu, 16 Oct 2014 13:39:03 +0530
From: gsmandvoip <[email protected]>
To: "Garver, Paul W" <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 50, Issue 7
Message-ID:
<CADE+fGCYi9=42nuukpkwwglh1ye690wa2c4ic4z4an6agw2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
@Peter,
can you share your code please, I want to acomplish 4MHz sampling rate with
my i3, 4GB ram machine, although have higher conf pc, but would like to
learn more about buffering implementation in uhd_rx_cfile and
rx_stream_to_file
Please do share your code and instruction.
Thank you
On Tue, Oct 7, 2014 at 10:05 PM, Garver, Paul W via USRP-users <
[email protected]> wrote:
> This discussion mentions many of the key issues I've found as well.
>
> My point was that the application in
> general can benefit from multi-threading and internal buffering, otherwise
> overflows are a fact of life for high data rates.
>
> Agreed, I've modified rx_samples_to_file with a two-thread
> producer-consumer model storing data in a circular buffer. Elements in the
> buffer are multiplies of the page size (4k on my system = 1k samples) for
> efficiency. I actually use a small buffer so that the program acts more
> like a "pipe" into the disk. The buffer is there for worst-case latencies
> / OS interrupts.
>
> When set to 0, I see in iotop that my
> writes are a consistent value which is right about where resource monitor
> shows the incoming 10GigE bandwidth to be. Setting the
> dirty_background_ratio any higher and the "Total Disk Write" and "Actual
> Disk Write" differ wildly. "Actual Disk Write" will spike at times, and
> these spikes correlate with additional overflow errors. When the device is
> more stable (i.e. "Actual Disk Write" is consistent) I see a huge reduction
> in overflows.
>
> I agree with this observation as well; however, I achieve constant write
> speeds by calling sync_file_range after every read. I'm not familiar with
> dirty background ratio, I'll have to look into that.
>
> I'd like to point out that most benchmarks use heavily averaged numbers
> > for write speeds etc. UHD on the other hand kind of demands soft
> real-time
> > performance of a write subsystem, which is a lot harder to fulfill.
>
> Again, absolutely true. All those numbers quoted by drive manufacturers
> don't guarantee performance according to our standards.
>
> With my modified program I'm able to record 25 MSPS (100MBytes/sec) with
> only very rare overflows on an Intel Haswell NUC i5 using a 1TB Samsung 840
> Evo mSATA drive. I've written over 2TB to the drive and rarely drop a
> sample. I can provide more details and code if anyone is interested. It
> is certainly not cross-platform due to the sync_file_range function. The
> takeaway point here for me is that rx_samples_to_file isn't the most
> efficient way to write data and you can get more out of your hardware if
> you optimize writes for you hardware.
>
> PWG
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 6 Oct 2014 15:33:22 -0400
> From: Peter Witkowski <[email protected]>
> To: "[email protected]" <[email protected]>
> Subject: Re: [USRP-users] rx_samples_to_file issue
> Message-ID:
> <
> can1qg3purhkjdesufy6sppdjoewfn0nixe4ypbxurv3bwsw...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Marcus,
>
> Great discussion so far.
>
> I think my point is that earlier I saw that it was alluded to that if
> rx_samples_to_file fails, then your disk subsystem is to blame and you
> should invest in more hardware. My point was that the application in
> general can benefit from multi-threading and internal buffering, otherwise
> overflows are a fact of life for high data rates. While the OS can do more
> buffering, you are required to do periodic (at a rather high rate) reads of
> the USRP, otherwise its buffers will overflow. This is why it is critical
> to minimize the time between two successive reads via threading and having
> a buffer that can concurrently be added onto (from the device) and
> processed (by writing to disk).
>
> I think we can agree that there's a delta between what the I/O can sustain
> (and what is displayed on a synthetic benchmark) versus what is actually
> happening on the machine. There's potentially a good deal of CPU cycles
> that occur between two reads (a vast percentage of these are during disk
> I/O, especially if the device is "busy") that seem to be causing the
> overflow. Stated differently, I can have a bunch of blocking reads occur
> and sustain the needed rate. Similarly (and this is what I see via my
> benchmarks), I can have a series of blocking writes occur and sustain the
> needed data rate. However, the combination thereof (as well as the fact
> that the kernel likes to preempt things) might be unsustainable in a single
> threaded application. That is, by the time I get to the next read, enough
> time has passed to overwhelm the USRP read buffers.
>
> My point with the dirty background ratio is that when set to zero, I have a
> predictable amount of time that I block for each write. My understanding
> is that once triggered, background flushes will attempt to write at 100%
> device speed. During this time, additional device access (such as those
> being called by the application) will be blocked (sequential writes are
> therefore performance degraded). When set to 0, I see in iotop that my
> writes are a consistent value which is right about where resource monitor
> shows the incoming 10GigE bandwidth to be. Setting the
> dirty_background_ratio any higher and the "Total Disk Write" and "Actual
> Disk Write" differ wildly. "Actual Disk Write" will spike at times, and
> these spikes correlate with additional overflow errors. When the device is
> more stable (i.e. "Actual Disk Write" is consistent) I see a huge reduction
> in overflows. Stated differently, I'm OK with a flush, as long as its a
> quick one. In the cases of larger flushes (as is the case with a
> dirty_background_ratio greater than 0), I can almost guarantee an overflow
> (I can't get around the mainloop fast enough if the device is busy with a
> long write). Note that for my buffered application, I do run a default
> background ratio.
>
> The only thing that I got to work was buffering, and the easiest way I know
> to accomplish this is to place a stream-to-vector block (in GNURadio)
> between the USRP source and the file sink. The vectorization effectively
> works as a buffer, and was the only way I was able to get 100 MS/s working.
>
> Other things I tried:
> 1. Using CPU affinity and shielding.
> 2. Increasing processes priority to 99 and SCHED_FIFO.
>
> Also, I can confirm that rx_samples_to_file and uhd_rx_cfile (as well as
> GNU Radio application that does effectively the same thing, but controls
> CPU affinity) all behave the exact same way in terms of the number of
> overflows I have encountered.
>
> If there are any other kernel tweaks that I can try, please let me know.
> However, in practice, my CPU is not fast enough to get through the mainloop
> of rx_samples_to_file quickly enough. As discussed above, buffering was
> the only way I was able to consistently ensure that my data was saved and I
> didn't encounter an overflow.
>
> If you would like, I can provide whatever benchmarks of the system that you
> would like. Perhaps I am not using the correct tool when I quote my
> minimum write speeds to disk.
>
> On Sat, Oct 4, 2014 at 9:14 AM, Marcus M?ller <[email protected]>
> wrote:
>
> > Hi Peter,
> >
> > didn't mean to confuse you! Actually, my job is doing the opposite (ie.
> > providing useful information), and thus let me just shortly follow up on
> > this:
> > On 03.10.2014 17:44, Peter Witkowski via USRP-users wrote:
> >
> > So I'm confused.
> >
> > You state that if I can't use rx_samples_to_file, my system is failing to
> > perform as specified to write data out, then you give an example of
> several
> > things that can happen to create a stochastic write speed (which I
> totally
> > understand and agree with). Given that writes can be stochastic, why is
> > there not a software buffer implemented in the UHD sample code to account
> > for such issues?
> >
> > Well, because that's, in my opinion, an operating system's job. Being a
> > code example, rx_samples_to_file just *musn't* contain the complexity
> > introduced when you try to implement buffering functionality smarter than
> > what your OS can do. And, I do think it's nearly impossible to be smarter
> > than the linux kernel when optimizing writes -- *but* you'll have to tell
> > your kernel what you want, as a user. The kernel, as it is configured by
> > any modern distribution by default, won't do enormous write buffers,
> > because that's not what the user usually wants, increasing the risk of
> data
> > loss in case of system failure, and because you usually don't want to
> spend
> > all of your RAM on filesystem buffers. In your 64GB RAM case, though,
> > default buffer sizes should suffice, I guess, so I'm a bit out of clues
> > here.
> > It is definitely not very hard to increase these buffers' sizes[1], so I
> > encourage you to try it and see if that solves your problem. Now, I must
> > admit that up to here I was always assuming you hadn't already played
> > around with these values, if this is not the case, please accept my
> > apologies!
> >
> > I understand that it's meant to be an example, but I've
> > also seen it referenced as being used effectively as a debugger or test
> for
> > people having issues (i.e. recommendation to use the UHD programs in
> place
> > of GNURadio to resolve issues).
> >
> > ...and it's done many users and thus Ettus a great job of supplying
> basic
> > functionality! The fact that it works in almost any situation with this
> > very minimalistic approach (repeated recv->write) proves that UHD is in
> > fact a rather nice driver interface, IMHO. The fact that GNU Radio
> > sometimes solves issues that rx_samples_to_file can't indicates exactly
> the
> > buffering approach to be helpful. But in that case, buffering is not
> > increased by increasing kernel buffer sizes, but by introducing GNU Radio
> > buffers between blocks. The USRP source (Martin, scold me if I say
> > something stupid) is not really much smarter than rx_samples_to_file: It
> > recv()s a packet of samples, and returns these samples from the work
> > function, and then GNU Radio takes care of shuffling and buffering that
> > data. Basically, GNU Radio behaves much like an operating system from the
> > source block's point of view.
> >
> > Also, in terms of benchmarking, I'm quoting minimum values, not averages.
> > I agree with you that average values are pointless, and in reality the
> disk
> > subsystem needs to perform when called up. My minimum values for a 4
> disk
> > RAID0 with a dedicated controller are well within the data rate that I am
> > pushing.
> >
> > Well, I'll kind of disagree with you: If your minimum write rate of your
> > system was bigger than the rate rx_samples_to_file causes, then you
> > wouldn't see the problem. The point, I believe, here is that the storage
> > system does not only consist of the hardware side of your RAID, but also
> on
> > your complete operating environment. Something slows down how fast data
> is
> > written to the RAID.
> > I think we both would expect the following to happen:
> >
> > repeatedly:
> >
> > rx_samples_to_file:
> > uhd::rx_streamer::recv
> > (blocks until a packet of samples has arrived. Instantly returns if
> it
> > has before the call)
> > write(file_handle, recv_buff)
> > (instantly returns, because writing should hit a buffer that the
> > operating system transparently pushes out to a disk. If buffer is full,
> > then block until enough space in buffer -- unless your filesystem is
> > mounted with some sync option...)
> >
> > Now, if your RAID is definitely fast enough, the write buffer should
> never
> > get full. My hypothesis here is that either, your buffer size is just to
> > small, and a block of samples doesn't fit and has to be written out
> > instantly (which is unlikely), or something else occupies your system.
> That
> > might be just the fact that 400MB/s (are we talking about an X3x0?)
> > inevitably places a heavy load on things like PCIe busses and CPUs, and
> > that introduces a bottleneck in your storage chain which isn't there if
> you
> > "just" benchmark without the USRP. Also, the rather smallish sizes of
> > network packets dictate that journalling file systems introduce a very
> bad
> > overhead -- I don't know if you benchmarked with files on a journaling
> file
> > system and a (network packet size - header) block size...
> >
> > Is there an example system that can handle sustained data capture from
> the
> > USRP at (or near the limits) of 10GigE or the PCIe interfaces (maybe the
> > requirement is enterprise class PCIe SSDs)? I'm running a two socket
> Xenon
> > system (two hex core processors) with 64GB of RAM. How much more
> hardware
> > should I throw at the problem to be able to sample/write at 100MS (half
> of
> > what is quoted on the website for bandwidth for the 10GigE kit) using the
> > provided code?
> >
> > Definitely a nice system! I must admit that I don't have access to a
> > comparable setup, and thus I can't really offer you any first-hand
> > experience. Maybe others can.
> >
> > I think the issue here is that the code itself can't simply get through
> > it's main loop fast enough. There's a difference between data bandwidth
> > and CPU throughput. The sequential nature of the code means that if any
> > weird stuff happens (your example was a good set of kernel related
> hilarity
> > that can lead to stochastic timing) you will have overflows since you
> > cannot read fast enough. This is why a 90% solution for my application
> was
> > to just set the dirty_background_ratio to 0 and also why redirection to
> > /dev/null makes overflows go away.
> >
> > This is interesting, as dirty_background_ratio is the percentage at
> which
> > the kernel should start writing out dirty pages in the background. Now,
> I'm
> > the one who's confused, because I would have expected this to negatively
> > impact performance. On the other hand, 0 (at least in my head) does not
> > make very much sense, maybe it's semantically identical to 100%? Are you
> > swapping (64GB would tell me you shouldn't have swap or extremly low
> > swappiness)?
> > On the other hand, it might really be that storage is not the bottleneck
> > here, and in fact maybe the CPU gets saturated. Now, you said that
> writing
> > to /dev/null solves your problem. Do your RAID or filesystem consume a
> lot
> > of CPU cycles? This is an interesting mystery...
> >
> > With either method I didn't have to
> > wait for a large write cache to flush before moving on to the next read
> > from the USRP. Note that there can also be things that happen on the
> read
> > side as well. Does this mean that I can only run the code on an RTOS?
> >
> > No :) UHD has it's own incoming buffer handlers, but as you already
> said,
> > in this high performance scenario, you might be totally right, and our
> > single-threaded approach just doesn't cut it. Maybe dropping in some
> > asynchronous storage IO would help -- but I hate seeing that blowing up
> in
> > example users' faces, so I guess the fact that it doesn't work with a
> > system as potent as yours with the sample rates as high as you demand
> might
> > actually be a shortcoming of the examples that isn't going to be fixed.
> >
> > As a final note, my understanding is that GNURadio and the USRP were
> > developed for domain experts in DSP to use.
> >
> > These are SDR frameworks and devices, respectively. The idea is to offer
> > people with the opportunity to build awesome DSP systems using
> universally
> > usable SDR blocks (GNU Radio) and universal software radio peripherals,
> so
> > well, they certainly address DSP people, but they shouldn't be hard to
> use.
> >
> > These users may or may not
> > have prior experience in software. As a result, I'd recommend perhaps
> > adding a buffered example or have the USRP GNURadio block allow for
> > buffering.
> >
> > That is something we might consider. On the other hand, when someone
> goes
> > as far as you do, maybe having an example that does the buffering in a
> > separate thread (or even process) isn't worth that much -- in the end,
> one
> > will want to write one's own high performance application, and that will
> > include handling such data rates.
> >
> > Otherwise, I just don't see how you can advertise 200 MS/s
> > (maybe even a simple "buffer" block in GNURadio would do the trick?).
> >
> > Well, the devices support these rates, and our driver is able to
> > withstand these rates and sustain them without hitting CPU barriers due
> to
> > having too much overhead. That's awesome (ok, I might be biased, but *I*
> > think it's awesome). I don't feel ashamed because on your specific setup,
> > we can't find a way to make any of our generic examples deliver the full
> > rate of rx streams to storage -- we sell RF hardware, and not storage
> > infrastructure, and the point of the examples is demonstrating the usage
> of
> > UHD, and not holding a lecture on high performance storage handling. I
> > wish, though, that we could solve your problem.
> >
> > Now, GNU Radio/gr-uhd does in fact come with an application called
> > uhd_rx_cfile, which is more or less a clone of rx_samples_to_file using
> > gr-uhd and GNU Radio instead of raw UHD. Does that work out for you?
> >
> > I
> > understand that this is theoretical limit of the bus, but if there
> doesn't
> > exist a driver or other software to make use of this, the practical limit
> > becomes much, much smaller.
> >
> > Well, UHD seems to be able to sustain these rates, if you write to
> > /dev/null, right? So the practical limit for UHD is definitely not being
> > hit.
> > I have another --maybe even practical-- suggestion to make: Roll your own
> > buffer!
> >
> > mkfifo /tmp/mybuffer #assuming tmpfs is in ram
> > dd if=/tmp/mybuffer of=/mount/raid_volume/data.dat & #start in
> background;
> > you could play around with block sizes using the bs= option of dd
> > rx_samples_to_file --file /tmp/mybuffer [all the other options]
> >
> > By the way: Thanks for bringing this up! We know that recording samples
> is
> > a core concern of many users.
> >
> > Greetings,
> > Marcus
> >
> > [1] https://www.kernel.org/doc/Documentation/sysctl/vm.txt
> >
> > On Fri, Oct 3, 2014 at 10:55 AM, Marcus M?ller <
> [email protected]> <[email protected]>
> > wrote:
> >
> >
> > I have to agree with Marcus on this. Also, keep in mind that storage is
> > really what an operating system should take care of in any "general
> > purpose" scenario, ie. that as long as I just write to a file, I'd expect
> > that the thing in charge of storage (my kernel / the filesystems / block
> > device drivers) does the best it can to keep up. If I find myself in a
> > situation where my specific storage needs dictate a huge write buffer,
> > changing the application might be one way, but as I'm responsible for my
> > won storage subsystem, I could just as well increase the cache buffer
> > sizes, and let the operating system handle storage operation. If your
> RAID
> > is really performing as well as it is benchmarked to, then this should
> not
> > be one of your problems. All rx_samples_to_file does is really
> sequentially
> > writing out data at a constant rate, which is the most basic write
> > benchmark I can think of.
> >
> > If your storage subsystem (filesystem + storage abstraction + raid driver
> > + interface driver + hard drive interface + hard drives + hardware
> caches)
> > can't keep up, it's failing to perform as specified, simple as that. In
> > this case, saying that the application needs to be smarter when dealing
> > with storage seems like a bit of a cop-out to me ;)
> >
> > I'd like to point out that most benchmarks use heavily averaged numbers
> > for write speeds etc. UHD on the other hand kind of demands soft
> real-time
> > performance of a write subsystem, which is a lot harder to fulfill. This
> > comes up rather frequently, but I have to stress it: you need a fast
> > guaranteed write rate, not only an average one, and as soon as your
> > operating system has to postpone writing data[1], it has to have enough
> > performance to catch up whilst still meeting continued demand. This is
> > general purpose hardware running general purpose OS with dozens of
> > processes, and you can't just say "every single component is up to my
> task,
> > thus my system suffices", because everything potentially blocks
> everything!
> >
> > Greetings,
> > Marcus
> >
> > [1] e.g. because the filesystems needs to calculate checksums, update
> > tables, another process gets scheduled, a device blocks your PCIe bus,
> your
> > platters randomly need a bit longer to seek, you reach the physical end
> of
> > an LVM volume and have to move across a disk, an interrupt does what an
> > interrupt does, some process is getting noticed on a changing file
> > descriptor, DBUS is happening in the kernel, token ring has run out of
> > tokens, thermal throttling, bitflips on SATA leading to retransmission,
> > some page getting fetched from swap...
> >
> >
> > On 03.10.2014 15:34, Marcus D. Leech via USRP-users wrote:
> >
> >
> >
> > One has to keep firmly in mind that programs like rx_samples_to_file are
> > *examples* that show how to use
> >
> > the underlying UHD API. They are not necessarily optimized for all
> > situations, and indeed, one could
> >
> > restructure rx_samples_to_file to decouple UHD I/O from filesystem I/O,
> > using a large buffer between them.
> >
> > The fact is that dynamic performance of high-speed, real-time, flows is
> > something that almost-invariably needs
> >
> > tweaking for any particular situation. There's no way for an example
> > application to meet all those requirements.
> >
> > But the fact also remains that for *some* systems, rx_samples_to_file
> > (and uhd_rx_cfile on the Gnu Radio side)
> >
> > are able to stream high-speed data just fine as-is.
> >
> > On 2014-10-03 09:26, Peter Witkowski via USRP-users wrote:
> >
> >
> > To say that the issue is just because the disk subsystem can't keep up
> is a bit of cop-out.
> >
> > I had issues writing to disk when the incoming stream was 400MB/s and my
> RAID0 system was benchmarked at being much higher than that.
> >
> > The issue that I've been seeing stems from the fact that it appears that
> you cannot concurrently read/write from the data stream as its coming in.
> In effect you have a main loop that reads from the device and then
> immediately tries to write that buffer to file. If you do not complete
> these operations in a timely fashion overflows occur.
> >
> > One way to solve (or at least band aid the issue) is to set your
> dirty_background_ratio to 0. I was able to get writing to disk working
> somewhat with this setting as it is more predictable to directly write to
> disk instead of having your write cache fill up and then having a large
> amount of data to push to disk. That said, my RAID0 array is capable of
> such speeds and even then I was getting a few (but much reduced) overflows.
> >
> > The one surefire way I know of getting this working (even on a slow disk
> system) is to buffer the data. The buffer can then be consumed by the disk
> writing process while being concurrently added onto by the device reader.
> The easiest way to test buffering (that I've found) is to simply set up a
> GNURadio Companion program with a stream-to-vector block between the USRP
> and file sink blocks. This is exactly what I am doing currently since even
> with a very powerful system, I could not get data saved to disk quickly
> enough given the aforementioned issues with the provided UHD software.
> >
> > On Thu, Oct 2, 2014 at 11:48 PM, gsmandvoip via USRP-users <
> [email protected]> <[email protected]> <
> [email protected]> <[email protected]> wrote:
> >
> > Thanks Marcus for your replies. Yes O gone away.
> >
> > On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <[email protected]> <
> [email protected]> <[email protected]> <[email protected]> wrote:
> >
> > with rx_samples_to_file without _4rx.rbf, Initially I tried on my i3,
> 4GB ram, it gave me
> > some OOOO but was lesser than earlier, but I do not understand, my most
> of the ram capacity and processor was sitting idle while it shows OOOO, why
> is this strange behaviour The default format for uhd_rx_cfile is
> complex-float, thus doubling the amount of data written compared to
> rx_samples_to_file.
> >
> > You can't just use CPU usage as an indicator of loading--if you're
> writing to disk, the disk subsystem may be much slower than you think, so
> the
> > "rate limiting step" is writes to the disk, not computational elements.
> >
> > Try using /dev/null as the file that you write to. If the 'O' go away,
> even at higher sampling rates, then it's your disk subsystem.
> >
> > using uhd_rx_cfile getting similar result, but strangely, why it is low,
> at 4M sampling rate it was higher???
> >
> > On Thu, Oct 2, 2014 at 9:27 AM, Marcus D. Leech <[email protected]> <
> [email protected]> <[email protected]> <[email protected]> wrote:
> >
> > On 10/01/2014 11:46 PM, gsmandvoip wrote:
> >
> > Yes I am running single channel, but when trying to achieve my desired
> sampling rate without _4rx.rbf, it says, requested sampling rate is not
> valid, adjusting to some 3.9M or so. sorry for misleading info I gave
> earlier, I have i3, with 32 bit and i7 with 64 bit, but getting same result
> on both machines
> >
> > Here is my command to capture signal:
> >
> > ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX"
> --freq "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
> >
> > and here is its output:
> >
> > Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
> > -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
> > -- Opening a USRP1 device...
> > -- Loading FPGA image: /usr/share/uhd/images/usrp1_
> > fpga_4rx.rbf... done
> > -- Using FPGA clock rate of 52.000000MHz...
> > ERROR: LOOKUPERROR: INDEXERROR: MULTI_USRP::GET_TX_SUBDEV_SPEC(0) FAILED
> TO MAKE DEFAULT SPEC - VALUEERROR: THE SUBDEVICE SPECIFICATION "A:0" IS TOO
> LONG.
> > The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
> >
> > Don't use the _4rx image if you don't need it.
> >
> > The USRP1 only does strict-integer resampling, and with a master clock
> (NON STANDARD FOR USRP1) of 52.000MHz, 4Msps is not a sample rate
> > that it can produce. Try 5.2Msps or 4.3333Msps.
> >
> > At 5.2Msps, it's recording at roughly 20.8Mbytes/second, so your system
> needs to be able to sustain that for at least as long as the capture lasts.
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing [email protected]://
> lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing [email protected]://
> lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing [email protected]://
> lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
>
>
> --
> Peter Witkowski
> [email protected]
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141006/ff0dc077/attachment-0001.html
> >
>
> ------------------------------
>
>
>
>
> _______________________________________________
> 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/20141016/5df165aa/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 16 Oct 2014 14:01:01 +0200
From: Martin Braun <[email protected]>
To: [email protected]
Subject: [USRP-users] Boost Requirements (Was: 3.8.0 build issues on
centos 6)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 10/15/2014 12:21 AM, Stan Vitebsky via USRP-users wrote:
> I have trouble building newly released uhd 3.8.0 on Centos 6 (3.10.33
> kernel).
> [...]
> I suppose this is because this file doesn't exist in boost 1.41, which
> is default for Centos 6.
> Does this mean that Centos 6 will no longer be supported by uhd?
Everyone,
we will indeed be bumping our minimum Boost version to 1.46 for 3.8.0.
As you've already discussed in this thread, this doesn't mean we CentOS
6 won't work anymore, as it's a simple matter to update Boost.
If you're using PyBombs to install UHD, this will automate the process
for you.
A short note on distros: We will make an effort to make UHD build on any
not-too-old Linux (and other OSes) that meet our dependencies, but we
mainly test on current Ubuntu and Fedora versions (those for which we
also provide binary installers), Mac OS X and Windows 7. If it doesn't
matter to you which distro you're using, we thus recommend Ubuntu or
Fedora, but as I said, we'll do our best to write portable code to make
it work on most platforms.
Cheers,
Martin
------------------------------
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 50, Issue 15
******************************************
