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. TX Image rejection B210 (Sebastian Held)
2. Re: IDE for working with UHD examples under Ubuntu 14.04 LTS
(Jeremy Hershberger)
3. E310 (Florian Schenk)
4. Re: TX Image rejection B210 (Martin Braun)
5. Re: E310 ([email protected])
6. Re: Phase offset drift over time for two x310 (Michael West)
7. Re: Again performance issues B210, while BladeRF performs
fine (Neel Pandeya)
8. Re: IDE for working with UHD examples under Ubuntu 14.04 LTS
(=?ISO-8859-1?B?VHJlaw==?=)
9. WBX-120 frequency range (Joel Bratin)
10. Re: WBX-120 frequency range (Marcus D. Leech)
11. Again performance issues B210, while BladeRF performs fine
(Ron Economos)
12. Help! (Genaro Pacurucu R.)
13. Re: PC performance optimization (Dario Fertonani)
14. Re: Again performance issues B210, while BladeRF performs
fine (Ralph A. Schmid, dk5ras)
15. Re: Again performance issues B210, while BladeRF performs
fine (Ralph A. Schmid, dk5ras)
16. Re: Again performance issues B210, while BladeRF performs
fine (Ralph A. Schmid, dk5ras)
17. Re: Again performance issues B210, while BladeRF performs
fine (Ron Economos)
18. Re: TX Image rejection B210 (Sebastian Held)
19. Looking for Ettus B210 old/white one ([email protected])
20. Re: Again performance issues B210, while BladeRF performs
fine (Ralph A. Schmid, dk5ras)
21. Re: Again performance issues B210, while BladeRF performs
fine (Ron Economos)
22. OpenBTS Subscriber Registration - E310 USRP (Amber and Sarosh)
23. Tx2Rx-Sine (siva sankar)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Mar 2015 08:50:56 +0200
From: Sebastian Held <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] TX Image rejection B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
I'm currently investigating a problem with my OFDM modulated signals. To
understand, why the spectrum mask is violated, I first checked the basic
TX parameters. The B210 is connected to a R&S FSQ26 via a 20 dB attenuator.
I use the examples provided with the UHD-release_003_008_002-10-ge067c45:
./tx_waveforms --args="master_clock_rate=20e6" --rate 20000000
--freq=5900000000 --gain=80 --wave-type SINE --ref=gpsdo --int-n
--wave-freq=1000000
This command results in an expected tone at 5.9 GHz + 1 MHz (approx. -29
dBm) and its image at 5.9 GHz - 1 MHz. The problem is: the image power
is very large: only 26 dB below the wanted 5.901 GHz tone. From the
AD9361 data sheet I would expect a suppression of at least 45 dB.
To continue to solve my original problem (OFDM spectrum) I first need to
understand, why I get such a large image.
Can I use this example to evaluate the TX image? Any pointers?
Regards,
Sebastian
--
Sebastian Held (Dipl.-Ing.)
IMST GmbH
Software Engineer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data_20MHz_rate.png
Type: image/png
Size: 90811 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150330/3c0b5671/attachment-0001.png>
------------------------------
Message: 2
Date: Mon, 30 Mar 2015 10:58:49 -0400
From: Jeremy Hershberger <[email protected]>
To: Trek <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] IDE for working with UHD examples under
Ubuntu 14.04 LTS
Message-ID:
<CAMZiKLof8j-dtVGoqHMXUKfc2A02i2WzRWz=qprppdkhd85...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have had good luck using Code::Blocks. It is pretty easy to install,
especially under ubuntu, and works well with UHD. If you do a quick
internet search for cmake+codeblocks you should be able to find the command
that will allow you to create a codeblocks project file directly from cmake
to work with UHD.
On Sun, Mar 29, 2015 at 7:45 PM, Trek via USRP-users <
[email protected]> wrote:
> would someone pl. recommend a good integrated IDE to work with UHD
> examples under Ubuntu?
> I am new to Linux.
>
> Thank you.
>
> _______________________________________________
> 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/20150330/2ae9a99f/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 30 Mar 2015 16:16:10 +0000
From: Florian Schenk <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310
Message-ID:
<e43b5432b04f4711a3c0556c4676f...@srv-exch-02.internal.convexis.de>
Content-Type: text/plain; charset="us-ascii"
Hi,
I can't get the network mode of the E310 to work. The connection is established
but I don't get any decent data rate. I tried the FM-radio example but with a
sampling rate of 2Mbit the connection works for several seconds (with buffer
underruns) and then closes. I'm using UHD 3.8.2 and the latest release SD card
image for the E310. Is there anything else I can try?
Thanks,
Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150330/3d5600ad/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 30 Mar 2015 09:46:26 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] TX Image rejection B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Sebastian,
what happens when you turn down the gain (e.g. to 70 dB)?
M
On 29.03.2015 23:50, Sebastian Held via USRP-users wrote:
> Hi,
>
> I'm currently investigating a problem with my OFDM modulated signals. To
> understand, why the spectrum mask is violated, I first checked the basic
> TX parameters. The B210 is connected to a R&S FSQ26 via a 20 dB attenuator.
>
> I use the examples provided with the UHD-release_003_008_002-10-ge067c45:
> ./tx_waveforms --args="master_clock_rate=20e6" --rate 20000000
> --freq=5900000000 --gain=80 --wave-type SINE --ref=gpsdo --int-n
> --wave-freq=1000000
>
> This command results in an expected tone at 5.9 GHz + 1 MHz (approx. -29
> dBm) and its image at 5.9 GHz - 1 MHz. The problem is: the image power
> is very large: only 26 dB below the wanted 5.901 GHz tone. From the
> AD9361 data sheet I would expect a suppression of at least 45 dB.
>
> To continue to solve my original problem (OFDM spectrum) I first need to
> understand, why I get such a large image.
> Can I use this example to evaluate the TX image? Any pointers?
>
> Regards,
> Sebastian
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Mon, 30 Mar 2015 12:59:09 -0400
From: [email protected]
To: Florian Schenk <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
2Msps is at the very outside of what network mode on the E310 can do.
Really, network mode was designed as a tool for quick sanity testing at
low sample rates. It's not the primary way the E3xx family is intended
to be used.
On 2015-03-30 12:16, Florian Schenk via USRP-users wrote:
> Hi,
>
> I can't get the network mode of the E310 to work. The connection is
> established but I don't get any decent data rate. I tried the FM-radio
> example but with a sampling rate of 2Mbit the connection works for several
> seconds (with buffer underruns) and then closes. I'm using UHD 3.8.2 and the
> latest release SD card image for the E310. Is there anything else I can try?
>
> Thanks,
>
> Florian
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20150330/6696e285/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 30 Mar 2015 10:54:50 -0700
From: Michael West <[email protected]>
To: Damiano Scanferla <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Phase offset drift over time for two x310
Message-ID:
<cam4xkrpopnjeh7wau-vxoczfebvabub+z+ds779vsrhtorv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Damiano,
The change Neel sent you was to reduce the oscillations, not the drift. We
are actively looking into the drift and will let you know what we find as
soon as possible.
Regards,
Michael
On Mon, Mar 30, 2015 at 8:18 AM, Damiano Scanferla via USRP-users <
[email protected]> wrote:
> Hello Neel,
>
> Thanks for your answer. I have tried what you suggested but we did not see
> any significant improvements:
> - the phase offset at 2.7 GHz drifted by 40 degrees over 3 minutes (same
> as before)
> - the oscillations of the phase offset over short time were reduced.
>
> Do you have a reason for this phase offset drift over time?
>
> Damiano
>
> On Mon, Mar 30, 2015 at 3:54 PM, Neel Pandeya <[email protected]>
> wrote:
>
>> Hello Damiano Scanferla:
>>
>> We have seen this issue before, and we believe that we have a solution
>> that should improve the results that you're seeing. I would like to ask you
>> to make a one-line change on line 193 of the file
>> "uhd/host/lib/usrp/x300/x300_clock_ctrl.cpp", and then re-build and
>> re-install UHD. I've attached a copy of the file with the change in it. It
>> is necessary that you are running UHD 3.8.2 for this to work. I assume that
>> you're on Linux, such as Ubuntu 14.04. Please let me know if you see better
>> results with this change, or if you have any problems making the code
>> change. Thanks.
>>
>> --Neel
>>
>>
>>
>> On 27 March 2015 at 05:58, Damiano Scanferla via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi,
>>>
>>> I would like to achieve phase alignment at two receivers being 2 SBX-120
>>> daughter-boards of either the same X310 or belonging to 2 different X310s.
>>>
>>> I can measure the phase offset between the two receivers and compensate
>>> for it. The problem is that the phase offset is not constant but it is
>>> drifting over time. Of course I can do a periodic calibration of the
>>> receivers but I read in several blogs that the phase offset should be
>>> constant so I am wondering what I am not doing properly in my setup.
>>>
>>> SETUP
>>> An RF signal at 800 MHz or 2700 MHz is generated with a signal generator
>>> (R&S SMJ100A) and fed to 2 daughter-boards via splitter and 2 cables of the
>>> same length. At the receiving USRPs, I just measure the phase difference
>>> between the samples received by receiver 1 and receiver 2 (phase offset).
>>> The USRPs get the 10 MHz ref and PPS from an OctoClock (both clock_source
>>> and time_source set to "external", and sync set to "unknown PPS").
>>>
>>> I have attached the "grc file" and the slope of the phase offset over 3
>>> minutes for the following configurations:
>>> - 800 MHz, 2 SBX-120 in 1 X310
>>> - 800 MHz, 1 SBX-120 in 2 different X310
>>> - 2700 MHz, 2 SBX-120 in 1 X310
>>> - 2700 MHz, 1 SBX-120 in 2 different X310
>>>
>>> 2 observations:
>>> - the higher the frequency, the higher the phase drift (almost linear
>>> with frequency). So, could it be due to a phase drift of the 10 MHz
>>> reference?
>>> - the phase drift is lower when the 2 daughter-boards belong to the same
>>> X310.
>>>
>>> Do you know what could be the reason for this? Have you ever seen such
>>> behaviour?
>>>
>>> Best regards,
>>> Damiano
>>>
>>>
>>> _______________________________________________
>>> 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/20150330/d55610d2/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 30 Mar 2015 11:21:55 -0700
From: Neel Pandeya <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
performs fine
Message-ID:
<CACaXmv9mf94QfDLxh_tY7DQBpb=mmnsh16zdbocvliwt3sa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Ralph:
Thanks for the feedback. There are two more things I'd like to ask you.
Could you run "dpkg -l | grep libusb" and "lspci", and post the results?
Also, so you see the same USB problems with the B210 if you run Linux on
the metal, instead of in a VM??
--Neel
On 30 March 2015 at 11:07, Ralph A. Schmid, dk5ras <[email protected]> wrote:
> Hi,
>
>
>
> It is Kubuntu 14.04, in a VM; the controller is some Intel thing, UHD is
> 3.8.2, built from source, libusb is something I never really cared about,
> but the system has 0.1-4, and 1.0-0 with dev files aboard. Nothing special,
> and everything works, even openLTE runs with the B210, but in comparing the
> performance B210/BladeRF this cheap Nuand thing usually runs ahead. I don't
> like paying double the price for half the performance :-) In fact I even
> wouldn't have considered buying the BladeRF if the B210 would have hit the
> market earlier...
>
>
>
> Ralph.
>
>
>
> *From:* Neel Pandeya [mailto:[email protected]]
> *Sent:* Monday, March 30, 2015 17:33
> *To:* Ralph A. Schmid, dk5ras
> *Cc:* usrp-users
> *Subject:* Re: [USRP-users] Again performance issues B210, while BladeRF
> performs fine
>
>
>
> Hello Ralph:
>
> I just want to double-check some facts with you before responding further.
> Are you using UHD 3.8.2? Which USB controller are you using on this system?
> Which Linux distribution, and which version of libusb? Thanks.
>
> --Neel
>
>
>
> On 30 March 2015 at 02:36, Ralph A. Schmid, dk5ras via USRP-users <
> [email protected]> wrote:
>
> Hi,
>
> I know, always the same moaning and groaning, but again I am a bit baffled.
> When trying to transmit DVB-T2 signals, using the example flowgraph from
> the
> gr-dvbt2, the B210 only allows stuttering transmission, printing lots of U,
> no matter, if I use the UHD or the osmocom sink to interface the
> transceiver. When I use osmocom sink with BladeRF, the signal is steady, no
> dropouts, and if I only already had the DVB-T2 receiver I have no doubt
> that
> it would be decodable. In fact it is enough to change the device in osmocom
> sink to either successfully transmit over the BladeRF or get broken
> transmission with the B210, the other settings and the flowgraph remain the
> same. There is some change when playing with buffers and buflen, but I
> achieved only slight improvements, far from being usable.
>
> All the stuff, UHD, bladeRF, gnuradio, osmocom and gr-dvbt2 is built form
> source and on latest release level. I am using latest FX3 and FPGA images
> for both B210 and BladeRF. The sample rate is 9.something MS/sec, nothing
> that should stress the system excessively.
>
> I have no idea who is eating up all the performance when using the B210. It
> is without doubt the nicer radio, has the better support throughout the SDR
> world - just the driver performance is driving me nuts :-(
>
> Maybe Ettus should hire the BladeRF developers?! :-)
>
> Ralph.
>
>
>
>
> _______________________________________________
> 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/20150330/8fe850eb/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 31 Mar 2015 02:32:59 +0800
From: "=?ISO-8859-1?B?VHJlaw==?=" <[email protected]>
To: "=?ISO-8859-1?B?SmVyZW15IEhlcnNoYmVyZ2Vy?=" <[email protected]>
Cc: Marcus M?ller via USRP-users <[email protected]>
Subject: Re: [USRP-users] IDE for working with UHD examples under
Ubuntu 14.04 LTS
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
great, code::blocks works with UHD like a charm,
Thanks,
------------------ Original ------------------
From: "Jeremy Hershberger";<[email protected]>;
Send time: Monday, Mar 30, 2015 10:58 PM
To: "Trek"<[email protected]>;
Cc: "usrp-users"<[email protected]>;
Subject: Re: [USRP-users] IDE for working with UHD examples under Ubuntu 14.04
LTS
I have had good luck using Code::Blocks. It is pretty easy to install,
especially under ubuntu, and works well with UHD. If you do a quick internet
search for cmake+codeblocks you should be able to find the command that will
allow you to create a codeblocks project file directly from cmake to work with
UHD.
On Sun, Mar 29, 2015 at 7:45 PM, Trek via USRP-users
<[email protected]> wrote:
would someone pl. recommend a good integrated IDE to work with UHD examples
under Ubuntu?
I am new to Linux.
Thank you.
_______________________________________________
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/20150331/8ede39b0/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 30 Mar 2015 21:28:34 +0000
From: Joel Bratin <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] WBX-120 frequency range
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
On the Ettus website I see that frequency range for the WBX-120 is 50MHz to
2.2GHz but when I call get_fe_tx_freq_range() or get_fe_rx_freq_range() I get
25MHz to 2.2GHz.
I see the same thing (25Mhz to 1.2GHz) with uhd_usrp_probe.exe. I am using UHD
3.8.2.
For the CBX-120 (1.2GHz to 6GHz) and the SBX-120 (400MHz to 4.4GHz) I get the
same values as I see online.
Which values are correct?
Thanks,
Joel Bratin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150330/5080b55e/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 30 Mar 2015 17:39:58 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] WBX-120 frequency range
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/30/2015 05:28 PM, Joel Bratin via USRP-users wrote:
>
> Hi,
>
> On the Ettus website I see that frequency range for the WBX-120 is
> 50MHz to 2.2GHz but when I call *get_fe_tx_freq_range()* or
> *get_fe_rx_freq_range()* I get 25MHz to 2.2GHz.
>
> I see the same thing (25Mhz to 1.2GHz) with uhd_usrp_probe.exe. I am
> using UHD 3.8.2.
>
> For the CBX-120 (1.2GHz to 6GHz) and the SBX-120 (400MHz to 4.4GHz) I
> get the same values as I see online.
>
> Which values are correct?
>
> Thanks,
>
> Joel Bratin
>
Recent versions of the drivers for the WBX have been able to pull the
synthesizer a bit lower, and when combined with the DDC in the FPGA, can
allow you to effectively tune down to 25Mhz, also, newer WBX cards
use the ADF4351, which has another couple of stages of output divider, as
compared to the ADF4350 on the first few revs of WBX.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150330/ca65efe4/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 30 Mar 2015 15:51:38 -0700
From: Ron Economos <[email protected]>
To: [email protected]
Subject: [USRP-users] Again performance issues B210, while BladeRF
performs fine
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Just joined the mailing list to respond to this question. I'm
the developer of gr-dvbt2 and coincidently, I've just bought
a B210.
The fix for the underruns is to add some buffering. In the
USRP Sink block Device Address field, add the following:
"send_frame_size=65536,num_send_frames=128"
This works well here with a VL80X based USB3.0 controller.
Ron
------------------------------
Message: 12
Date: Mon, 30 Mar 2015 18:17:25 -0500
From: "Genaro Pacurucu R." <[email protected]>
To: <[email protected]>
Cc: 'Diego Alc?cer' <[email protected]>
Subject: [USRP-users] Help!
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Dear ETTUS Sirs,
I am writing from Ecuador South America. I am new in GNU Radio. I am
planning use an USRP B210. I will travel to Washington DC the next week and
I want to know if somebody in Washington or nearest can help me with a short
training (basics) about the USRP B210 use (In special the wifi an cellular
communications if is possible). If this training has some costs don?t worry
I can pay. Please your help.
Best Regards,
Ing. Genaro Pacurucu R.
SISTEMAS TECNOL?GICOS
Miguel Alvarez Cortez Oe2-89 y Santiago Videla
Urbanizaci?n Bakker II
Telf. 593 2 6043210 - 6036517 - 2416448 - 2416211
Quito - Ecuador
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150330/78fc2654/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 30 Mar 2015 19:57:20 -0700
From: Dario Fertonani <[email protected]>
To: Rob Kossler <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<cajgedahyp0xzo1jyrosusccwwn9mgo+wyjzsxqqk6hztxm2...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
A way of forcing the performance governor in Ubuntu 14.04 and above so that
it survives reboot is as follows.
sudo apt-get install cpufrequtils
sudo echo "GOVERNOR="performance"" > /etc/defaults/cpufrequtils
sudo update-rc.d ondemand disable
I didn't read the full thread, but I thought the last one was missing in
Rob's case.
Source below. It did work for me.
http://askubuntu.com/questions/523640/how-i-can-disable-cpu-frequency-scaling-and-set-the-system-to-performance
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150330/6a3b8392/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 31 Mar 2015 08:13:23 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Ron Economos'" <[email protected]>
Cc: 'usrp-users' <[email protected]>
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
performs fine
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hey, thanks a lot, I will give this a try later this day! What do you
recommend, the osmocom sink, or the UHD sink?
Ralph.
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Ron Economos via USRP-users
> Sent: Tuesday, March 31, 2015 12:52 AM
> To: [email protected]
> Subject: [USRP-users] Again performance issues B210, while BladeRF
> performs fine
>
> Just joined the mailing list to respond to this question. I'm the
developer of
> gr-dvbt2 and coincidently, I've just bought a B210.
>
> The fix for the underruns is to add some buffering. In the USRP Sink block
> Device Address field, add the following:
>
> "send_frame_size=65536,num_send_frames=128"
>
> This works well here with a VL80X based USB3.0 controller.
>
> Ron
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 15
Date: Tue, 31 Mar 2015 08:15:53 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Neel Pandeya'" <[email protected]>
Cc: 'usrp-users' <[email protected]>
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
performs fine
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Here the output:
ras@ubuntu:~$ dpkg -l | grep libusb
ii libgusb2:amd64 0.1.6-5
amd64 GLib wrapper around libusb1
ii libusb-0.1-4:amd64 2:0.1.12-23.3ubuntu1
amd64 userspace USB programming library
ii libusb-1.0-0:amd64 2:1.0.17-1ubuntu2
amd64 userspace USB programming library
ii libusb-1.0-0-dev:amd64 2:1.0.17-1ubuntu2
amd64 userspace USB programming library development files
ii libusb-1.0-doc 2:1.0.17-1ubuntu2
all documentation for userspace USB programming
ii libusb-dev 2:0.1.12-23.3ubuntu1
amd64 userspace USB programming library development files
ii libusbmuxd2 1.0.8-2ubuntu1
amd64 USB multiplexor daemon for iPhone and iPod Touch devices -
library
ras@ubuntu:~$
ras@ubuntu:~$ lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge
(rev 01)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge
(rev 01)
00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 08)
00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
00:07.7 System peripheral: VMware Virtual Machine Communication Interface (rev
10)
00:0f.0 VGA compatible controller: VMware SVGA II Adapter
00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 01)
00:11.0 PCI bridge: VMware PCI bridge (rev 02)
00:15.0 PCI bridge: VMware PCI Express Root Port (rev 01)
00:15.1 PCI bridge: VMware PCI Express Root Port (rev 01)
00:15.2 PCI bridge: VMware PCI Express Root Port (rev 01)
00:15.3 PCI bridge: VMware PCI Express Root Port (rev 01)
00:15.4 PCI bridge: VMware PCI Express Root Port (rev 01)
00:15.5 PCI bridge: VMware PCI Express Root Port (rev 01)
00:15.6 PCI bridge: VMware PCI Express Root Port (rev 01)
00:15.7 PCI bridge: VMware PCI Express Root Port (rev 01)
00:16.0 PCI bridge: VMware PCI Express Root Port (rev 01)
00:16.1 PCI bridge: VMware PCI Express Root Port (rev 01)
00:16.2 PCI bridge: VMware PCI Express Root Port (rev 01)
00:16.3 PCI bridge: VMware PCI Express Root Port (rev 01)
00:16.4 PCI bridge: VMware PCI Express Root Port (rev 01)
00:16.5 PCI bridge: VMware PCI Express Root Port (rev 01)
00:16.6 PCI bridge: VMware PCI Express Root Port (rev 01)
00:16.7 PCI bridge: VMware PCI Express Root Port (rev 01)
00:17.0 PCI bridge: VMware PCI Express Root Port (rev 01)
00:17.1 PCI bridge: VMware PCI Express Root Port (rev 01)
00:17.2 PCI bridge: VMware PCI Express Root Port (rev 01)
00:17.3 PCI bridge: VMware PCI Express Root Port (rev 01)
00:17.4 PCI bridge: VMware PCI Express Root Port (rev 01)
00:17.5 PCI bridge: VMware PCI Express Root Port (rev 01)
00:17.6 PCI bridge: VMware PCI Express Root Port (rev 01)
00:17.7 PCI bridge: VMware PCI Express Root Port (rev 01)
00:18.0 PCI bridge: VMware PCI Express Root Port (rev 01)
00:18.1 PCI bridge: VMware PCI Express Root Port (rev 01)
00:18.2 PCI bridge: VMware PCI Express Root Port (rev 01)
00:18.3 PCI bridge: VMware PCI Express Root Port (rev 01)
00:18.4 PCI bridge: VMware PCI Express Root Port (rev 01)
00:18.5 PCI bridge: VMware PCI Express Root Port (rev 01)
00:18.6 PCI bridge: VMware PCI Express Root Port (rev 01)
00:18.7 PCI bridge: VMware PCI Express Root Port (rev 01)
02:00.0 USB controller: VMware USB1.1 UHCI Controller
02:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet
Controller (Copper) (rev 01)
02:02.0 Multimedia audio controller: Ensoniq ES1371 / Creative Labs CT2518
[AudioPCI-97] (rev 02)
02:03.0 USB controller: VMware USB2 EHCI Controller
02:05.0 SATA controller: VMware SATA AHCI controller
03:00.0 USB controller: VMware Device 0779
ras@ubuntu:~$
Ralph.
From: Neel Pandeya [mailto:[email protected]]
Sent: Monday, March 30, 2015 20:22
To: Ralph A. Schmid, dk5ras
Cc: usrp-users
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF performs
fine
Hello Ralph:
Thanks for the feedback. There are two more things I'd like to ask you.
Could you run "dpkg -l | grep libusb" and "lspci", and post the results?
Also, so you see the same USB problems with the B210 if you run Linux on the
metal, instead of in a VM??
--Neel
On 30 March 2015 at 11:07, Ralph A. Schmid, dk5ras <[email protected]> wrote:
Hi,
It is Kubuntu 14.04, in a VM; the controller is some Intel thing, UHD is 3.8.2,
built from source, libusb is something I never really cared about, but the
system has 0.1-4, and 1.0-0 with dev files aboard. Nothing special, and
everything works, even openLTE runs with the B210, but in comparing the
performance B210/BladeRF this cheap Nuand thing usually runs ahead. I don't
like paying double the price for half the performance :-) In fact I even
wouldn't have considered buying the BladeRF if the B210 would have hit the
market earlier...
Ralph.
From: Neel Pandeya [mailto:[email protected]]
Sent: Monday, March 30, 2015 17:33
To: Ralph A. Schmid, dk5ras
Cc: usrp-users
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF performs
fine
Hello Ralph:
I just want to double-check some facts with you before responding further. Are
you using UHD 3.8.2? Which USB controller are you using on this system? Which
Linux distribution, and which version of libusb? Thanks.
--Neel
On 30 March 2015 at 02:36, Ralph A. Schmid, dk5ras via USRP-users
<[email protected]> wrote:
Hi,
I know, always the same moaning and groaning, but again I am a bit baffled.
When trying to transmit DVB-T2 signals, using the example flowgraph from the
gr-dvbt2, the B210 only allows stuttering transmission, printing lots of U,
no matter, if I use the UHD or the osmocom sink to interface the
transceiver. When I use osmocom sink with BladeRF, the signal is steady, no
dropouts, and if I only already had the DVB-T2 receiver I have no doubt that
it would be decodable. In fact it is enough to change the device in osmocom
sink to either successfully transmit over the BladeRF or get broken
transmission with the B210, the other settings and the flowgraph remain the
same. There is some change when playing with buffers and buflen, but I
achieved only slight improvements, far from being usable.
All the stuff, UHD, bladeRF, gnuradio, osmocom and gr-dvbt2 is built form
source and on latest release level. I am using latest FX3 and FPGA images
for both B210 and BladeRF. The sample rate is 9.something MS/sec, nothing
that should stress the system excessively.
I have no idea who is eating up all the performance when using the B210. It
is without doubt the nicer radio, has the better support throughout the SDR
world - just the driver performance is driving me nuts :-(
Maybe Ettus should hire the BladeRF developers?! :-)
Ralph.
_______________________________________________
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/20150331/f5a6b60c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150331/f5a6b60c/attachment-0001.sig>
------------------------------
Message: 16
Date: Tue, 31 Mar 2015 08:31:54 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Neel Pandeya'" <[email protected]>
Cc: 'usrp-users' <[email protected]>
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
performs fine
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Neel,
I do not have the possibility to run it on bare metal at the moment, but at
least the experiences of a friend are similar, the performance is OK, but not
as good as expected, lots of U and such with higher sampling rate applications
like OpenLTE. Stuff begins getting difficult at around 10 MS/sec.
I will send the output in a second email.
Another thing, again my RF swiitch matrix was fried, although I have fitted ESD
protection diodes. They did not help at all :( I really hesitate having it
repaired once again for 50 bucks, just to see it die again within weeks. If
only those switches were easier to replace, this really is a point of failure.
I really wait for a comparable UHD radio (50-6000MHz, USB3) with a filter bank,
what gives some additional protection. I need a reliable radio, not one that
dies every few weeks from normal indoor usage with rubber duck antennae.
Thank you for the assistance!
Ralph.
From: Neel Pandeya [mailto:[email protected]]
Sent: Monday, March 30, 2015 8:22 PM
To: Ralph A. Schmid, dk5ras
Cc: usrp-users
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF performs
fine
Hello Ralph:
Thanks for the feedback. There are two more things I'd like to ask you.
Could you run "dpkg -l | grep libusb" and "lspci", and post the results?
Also, so you see the same USB problems with the B210 if you run Linux on the
metal, instead of in a VM??
--Neel
On 30 March 2015 at 11:07, Ralph A. Schmid, dk5ras <[email protected]
<mailto:[email protected]> > wrote:
Hi,
It is Kubuntu 14.04, in a VM; the controller is some Intel thing, UHD is 3.8.2,
built from source, libusb is something I never really cared about, but the
system has 0.1-4, and 1.0-0 with dev files aboard. Nothing special, and
everything works, even openLTE runs with the B210, but in comparing the
performance B210/BladeRF this cheap Nuand thing usually runs ahead. I don't
like paying double the price for half the performance :-) In fact I even
wouldn't have considered buying the BladeRF if the B210 would have hit the
market earlier...
Ralph.
From: Neel Pandeya [mailto:[email protected]
<mailto:[email protected]> ]
Sent: Monday, March 30, 2015 17:33
To: Ralph A. Schmid, dk5ras
Cc: usrp-users
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF performs
fine
Hello Ralph:
I just want to double-check some facts with you before responding further. Are
you using UHD 3.8.2? Which USB controller are you using on this system? Which
Linux distribution, and which version of libusb? Thanks.
--Neel
On 30 March 2015 at 02:36, Ralph A. Schmid, dk5ras via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
Hi,
I know, always the same moaning and groaning, but again I am a bit baffled.
When trying to transmit DVB-T2 signals, using the example flowgraph from the
gr-dvbt2, the B210 only allows stuttering transmission, printing lots of U,
no matter, if I use the UHD or the osmocom sink to interface the
transceiver. When I use osmocom sink with BladeRF, the signal is steady, no
dropouts, and if I only already had the DVB-T2 receiver I have no doubt that
it would be decodable. In fact it is enough to change the device in osmocom
sink to either successfully transmit over the BladeRF or get broken
transmission with the B210, the other settings and the flowgraph remain the
same. There is some change when playing with buffers and buflen, but I
achieved only slight improvements, far from being usable.
All the stuff, UHD, bladeRF, gnuradio, osmocom and gr-dvbt2 is built form
source and on latest release level. I am using latest FX3 and FPGA images
for both B210 and BladeRF. The sample rate is 9.something MS/sec, nothing
that should stress the system excessively.
I have no idea who is eating up all the performance when using the B210. It
is without doubt the nicer radio, has the better support throughout the SDR
world - just the driver performance is driving me nuts :-(
Maybe Ettus should hire the BladeRF developers?! :-)
Ralph.
_______________________________________________
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/20150331/3d620e91/attachment-0001.html>
------------------------------
Message: 17
Date: Mon, 30 Mar 2015 23:54:44 -0700
From: Ron Economos <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: 'usrp-users' <[email protected]>
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
performs fine
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'm using the UHD sink.
BTW, the AD9361 has built-in sin(x)/x correction, so you should
set that option to "Off" in the Pilot Generator and IFFT block.
It will still work fine either way, but the correct setting is "Off"
for B210 and "On" for bladeRF.
Also, if you still end up with performance issues, the vv009-4kfft.grc
test flow graph requires quite a bit less CPU performance than the
vv003-cr23.grc test flow graph.
Ron
On 03/30/2015 11:13 PM, Ralph A. Schmid, dk5ras wrote:
> Hey, thanks a lot, I will give this a try later this day! What do you
> recommend, the osmocom sink, or the UHD sink?
>
> Ralph.
>
>
>> -----Original Message-----
>> From: USRP-users [mailto:[email protected]] On Behalf Of
>> Ron Economos via USRP-users
>> Sent: Tuesday, March 31, 2015 12:52 AM
>> To: [email protected]
>> Subject: [USRP-users] Again performance issues B210, while BladeRF
>> performs fine
>>
>> Just joined the mailing list to respond to this question. I'm the
> developer of
>> gr-dvbt2 and coincidently, I've just bought a B210.
>>
>> The fix for the underruns is to add some buffering. In the USRP Sink block
>> Device Address field, add the following:
>>
>> "send_frame_size=65536,num_send_frames=128"
>>
>> This works well here with a VL80X based USB3.0 controller.
>>
>> Ron
>>
------------------------------
Message: 18
Date: Tue, 31 Mar 2015 09:51:24 +0200
From: Sebastian Held <[email protected]>
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] TX Image rejection B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
forgot to include the list.
Dear Martin,
please see attached figure. Reducing the gain acts on both the wanted
and unwanted signal in the same manner.
Sebastian
Am 30.03.2015 um 18:46 schrieb Martin Braun via USRP-users:
> Sebastian,
>
> what happens when you turn down the gain (e.g. to 70 dB)?
>
> M
>
> On 29.03.2015 23:50, Sebastian Held via USRP-users wrote:
>> Hi,
>>
>> I'm currently investigating a problem with my OFDM modulated signals. To
>> understand, why the spectrum mask is violated, I first checked the basic
>> TX parameters. The B210 is connected to a R&S FSQ26 via a 20 dB
>> attenuator.
>>
>> I use the examples provided with the
>> UHD-release_003_008_002-10-ge067c45:
>> ./tx_waveforms --args="master_clock_rate=20e6" --rate 20000000
>> --freq=5900000000 --gain=80 --wave-type SINE --ref=gpsdo --int-n
>> --wave-freq=1000000
>>
>> This command results in an expected tone at 5.9 GHz + 1 MHz (approx. -29
>> dBm) and its image at 5.9 GHz - 1 MHz. The problem is: the image power
>> is very large: only 26 dB below the wanted 5.901 GHz tone. From the
>> AD9361 data sheet I would expect a suppression of at least 45 dB.
>>
>> To continue to solve my original problem (OFDM spectrum) I first need to
>> understand, why I get such a large image.
>> Can I use this example to evaluate the TX image? Any pointers?
>>
>> Regards,
>> Sebastian
>>
>>
>>
>> _______________________________________________
>> 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
>
--
Sebastian Held (Dipl.-Ing.)
IMST GmbH
Software Engineer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gainreduction.png
Type: image/png
Size: 49393 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150331/ca4e1215/attachment-0001.png>
------------------------------
Message: 19
Date: Tue, 31 Mar 2015 11:42:39 +0200
From: [email protected]
To: [email protected]
Subject: [USRP-users] Looking for Ettus B210 old/white one
Message-ID:
<trinity-e2e679e2-6abf-4fe9-ac82-22684fddd02e-1427794958990@3capp-webde-bs06>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150331/d8c83044/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 31 Mar 2015 12:09:13 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Ron Economos'" <[email protected]>
Cc: 'usrp-users' <[email protected]>
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
performs fine
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
OK, with your tips the signal is less broken, but still not stable; I
already was using the vv009-4kfft.grc anyway. CPU is running at around 80%,
not critical, but who knows?! I will try tweaking a bit if I can get it more
stable. This is a very interesting case for fine tuning, as it is right at
the edge small changes get visible at once.
Edit before sending: Now I have a solid signal, after assigning 4 cores to
the VM. Just the question remains, why does the B210 use the given resources
so bad, compared to the BladeRF? And still I am not sure if I'd better use
four virtual cores, or two virtual cores with two "virtual-virtual" ones
each :) At first sight both variants behave identical.
Reception of the signal needs to wait until the DVB-T2 receiver is here, I
expect it by next week. The DVB-T package I did not get to run, it
transmits, but only some garble. The gnuradio fft view looks perfect, but
the real spectrum is completely different, both with BladeRF and B210 it is
the same crap coming out of the antenna. Maybe I missed something...
Ralph.
> -----Original Message-----
> From: Ron Economos [mailto:[email protected]]
> Sent: Tuesday, March 31, 2015 8:55 AM
> To: Ralph A. Schmid, dk5ras
> Cc: 'usrp-users'
> Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
> performs fine
>
> I'm using the UHD sink.
>
> BTW, the AD9361 has built-in sin(x)/x correction, so you should set that
> option to "Off" in the Pilot Generator and IFFT block.
> It will still work fine either way, but the correct setting is "Off"
> for B210 and "On" for bladeRF.
>
> Also, if you still end up with performance issues, the vv009-4kfft.grc
test flow
> graph requires quite a bit less CPU performance than the vv003-cr23.grc
test
> flow graph.
>
> Ron
>
> On 03/30/2015 11:13 PM, Ralph A. Schmid, dk5ras wrote:
> > Hey, thanks a lot, I will give this a try later this day! What do you
> > recommend, the osmocom sink, or the UHD sink?
> >
> > Ralph.
> >
> >
> >> -----Original Message-----
> >> From: USRP-users [mailto:[email protected]] On
> >> Behalf Of Ron Economos via USRP-users
> >> Sent: Tuesday, March 31, 2015 12:52 AM
> >> To: [email protected]
> >> Subject: [USRP-users] Again performance issues B210, while BladeRF
> >> performs fine
> >>
> >> Just joined the mailing list to respond to this question. I'm the
> > developer of
> >> gr-dvbt2 and coincidently, I've just bought a B210.
> >>
> >> The fix for the underruns is to add some buffering. In the USRP Sink
> >> block Device Address field, add the following:
> >>
> >> "send_frame_size=65536,num_send_frames=128"
> >>
> >> This works well here with a VL80X based USB3.0 controller.
> >>
> >> Ron
> >>
------------------------------
Message: 21
Date: Tue, 31 Mar 2015 03:49:52 -0700
From: Ron Economos <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: 'usrp-users' <[email protected]>
Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
performs fine
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
For the DVB-T transmit flow, delete the Rational Resampler
block and set the sample rate to (8000000.0 * 8) / 7 for an
8 MHz wide channel. For other channel widths, the sample
rate formula is:
(8000000.0 * channel width in MHz) / 7
On my setup, I'm getting better performance with the B210.
I was just doing some testing with the DVB-S2 flow, and I
was able to do 36 Msps. With bladeRF, I can't go over 24 Msps.
It all seems to be related to the USB3.0 controller. On the
B210, I'm using a VL80X based controller, which seems
pretty fast.
On bladeRF, the VL80X controller doesn't work well at all
and causes hard crashes (where you have to power down
to recover). I have to use the built-in NEC uPD720200
controller instead. It's slower, but solid as a rock.
Ron
On 03/31/2015 03:09 AM, Ralph A. Schmid, dk5ras wrote:
> OK, with your tips the signal is less broken, but still not stable; I
> already was using the vv009-4kfft.grc anyway. CPU is running at around 80%,
> not critical, but who knows?! I will try tweaking a bit if I can get it more
> stable. This is a very interesting case for fine tuning, as it is right at
> the edge small changes get visible at once.
>
> Edit before sending: Now I have a solid signal, after assigning 4 cores to
> the VM. Just the question remains, why does the B210 use the given resources
> so bad, compared to the BladeRF? And still I am not sure if I'd better use
> four virtual cores, or two virtual cores with two "virtual-virtual" ones
> each :) At first sight both variants behave identical.
>
> Reception of the signal needs to wait until the DVB-T2 receiver is here, I
> expect it by next week. The DVB-T package I did not get to run, it
> transmits, but only some garble. The gnuradio fft view looks perfect, but
> the real spectrum is completely different, both with BladeRF and B210 it is
> the same crap coming out of the antenna. Maybe I missed something...
>
> Ralph.
>
>> -----Original Message-----
>> From: Ron Economos [mailto:[email protected]]
>> Sent: Tuesday, March 31, 2015 8:55 AM
>> To: Ralph A. Schmid, dk5ras
>> Cc: 'usrp-users'
>> Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
>> performs fine
>>
>> I'm using the UHD sink.
>>
>> BTW, the AD9361 has built-in sin(x)/x correction, so you should set that
>> option to "Off" in the Pilot Generator and IFFT block.
>> It will still work fine either way, but the correct setting is "Off"
>> for B210 and "On" for bladeRF.
>>
>> Also, if you still end up with performance issues, the vv009-4kfft.grc
> test flow
>> graph requires quite a bit less CPU performance than the vv003-cr23.grc
> test
>> flow graph.
>>
>> Ron
>>
>> On 03/30/2015 11:13 PM, Ralph A. Schmid, dk5ras wrote:
>>> Hey, thanks a lot, I will give this a try later this day! What do you
>>> recommend, the osmocom sink, or the UHD sink?
>>>
>>> Ralph.
>>>
>>>
>>>> -----Original Message-----
>>>> From: USRP-users [mailto:[email protected]] On
>>>> Behalf Of Ron Economos via USRP-users
>>>> Sent: Tuesday, March 31, 2015 12:52 AM
>>>> To: [email protected]
>>>> Subject: [USRP-users] Again performance issues B210, while BladeRF
>>>> performs fine
>>>>
>>>> Just joined the mailing list to respond to this question. I'm the
>>> developer of
>>>> gr-dvbt2 and coincidently, I've just bought a B210.
>>>>
>>>> The fix for the underruns is to add some buffering. In the USRP Sink
>>>> block Device Address field, add the following:
>>>>
>>>> "send_frame_size=65536,num_send_frames=128"
>>>>
>>>> This works well here with a VL80X based USB3.0 controller.
>>>>
>>>> Ron
>>>>
>
------------------------------
Message: 22
Date: Tue, 31 Mar 2015 15:58:44 +0500
From: Amber and Sarosh <[email protected]>
To: "[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>, "[email protected]"
<[email protected]>
Cc: "[email protected]" <[email protected]>, Sir wajid
<[email protected]>
Subject: [USRP-users] OpenBTS Subscriber Registration - E310 USRP
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi
We are following this wiki http://openbts.org/w/index.php/E3x0 in order to
install OpenBTS along with all the other dependencies on Ettus USRP E310. After
the installation, when OpenBTS and subscriber registry are run, network is
detected but no mobile handset is able to register to the network. The command
"tmsis" also prints an empty TMSI Table. Please inform if anything else needs
to be done in addition to following the steps in the wiki.
Regards,
Amber, Sarosh & Naheed
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150331/94fc9f81/attachment-0001.html>
------------------------------
Message: 23
Date: Tue, 31 Mar 2015 17:59:37 +0530
From: siva sankar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Tx2Rx-Sine
Message-ID:
<caaubjivmxbbbvxwd96oe2nfvug_m_qzzoz-pampgqqnmhec...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
We are trying to transmit a sine wave and receive at both the receivers
simultaneously which is then written into a .dat file. We then plotted the
imaginary part, which matches the transmitted sine wave and the real part
doesn't look like a sine wave.
This is how we are writing the imag/real part to a .txt file, reading it
from .dat file and then plotting the same using octave.
input_file1.read((char*)&data, sizeof(data));
output_file1<<data.real()<<"\n";
or
input_file1.read((char*)&data, sizeof(data));
output_file1<<data.imag()<<"\n";
Below I am attaching the pictures of the output of the real and imaginary
part. I am also attaching the .dat file generated after executing the
program.
Can someone please explain this behavior?
Thanks
Siva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150331/53590eb4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Rx1_sinewave.dat
Type: application/x-ns-proxy-autoconfig
Size: 304000 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150331/53590eb4/attachment-0001.dat>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: real_sine.png
Type: image/png
Size: 15519 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150331/53590eb4/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imag_sine.png
Type: image/png
Size: 16076 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150331/53590eb4/attachment-0003.png>
------------------------------
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 55, Issue 30
******************************************
