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. RFNOC - multiply TX and RX streams (multiple block ports in a
single RFNoC block to multiply) (Itay Cnaan-On)
2. Re: RFNOC - multiply TX and RX streams (multiple block ports
in a single RFNoC block to multiply) (Martin Braun)
3. Re: 2 X310 motherboards with 4 channel receive (Martin Braun)
4. Re: 2 X310 motherboards with 4 channel receive
(=?ISO-8859-1?B?VHJlaw==?=)
5. RFNOC - rfnoc_adder example (Itay Cnaan-On)
6. List valid subdev specs? (Raj Bhattacharjea)
7. Re: RFNOC - rfnoc_adder example (Jonathon Pendlum)
8. Re: List valid subdev specs? (Martin Braun)
9. Rx/Tx Loopback (Rob Kossler)
10. Re: Rx/Tx Loopback (Richard Bell)
11. Could this be Ettus X310 self jamming problem?
(=?ISO-8859-1?B?VHJlaw==?=)
12. Re: Rx/Tx Loopback (Marcus D. Leech)
13. Re: Rx/Tx Loopback (Rob Kossler)
14. Re: Rx/Tx Loopback (Marcus D. Leech)
15. Re: Rx/Tx Loopback (Rob Kossler)
16. Re: Rx/Tx Loopback (Marcus D. Leech)
17. Re: Rx/Tx Loopback (Rob Kossler)
18. Re: Rx/Tx Loopback (Rob Kossler)
19. Re: Rx/Tx Loopback (Marcus D. Leech)
20. Re: Rx/Tx Loopback (Marcus D. Leech)
21. DVB-x (was: Again performance issues B210, while BladeRF
performs fine) (Ralph A. Schmid, dk5ras)
22. Cloning E310 Firmware (Amber and Sarosh)
23. Re: DVB-x (was: Again performance issues B210, while BladeRF
performs fine) (Ron Economos)
24. FW: DVB-x (was: Again performance issues B210, while BladeRF
performs fine) (Ralph A. Schmid, dk5ras)
25. Question: new (green) USRP B210 and Takachi enclosure
(Piotr Krysik)
26. Re: Question: new (green) USRP B210 and Takachi enclosure (David)
27. Re: Question: new (green) USRP B210 and Takachi enclosure
(Marcus M?ller)
28. Re: Question: new (green) USRP B210 and Takachi enclosure
(Piotr Krysik)
29. Re: Could this be Ettus X310 self jamming problem?
(=?ISO-8859-1?B?VHJlaw==?=)
30. Re: Could this be Ettus X310 self jamming problem?
(Sylvain Munaut)
31. Re: Could this be Ettus X310 self jamming problem? (Marcus M?ller)
32. ??? Could this be Ettus X310 self jamming problem?
(=?gb18030?B?VHJlaw==?=)
33. Re: Rx/Tx Loopback (Rob Kossler)
34. USRP source channel bandwidth setting with GRC
(=?utf-8?B?VHJlaw==?=)
35. Re: USRP source channel bandwidth setting with GRC
([email protected])
36. Re: Rx/Tx Loopback ([email protected])
37. problem with MISO signal receiving (scott tiger)
----------------------------------------------------------------------
Message: 1
Date: Wed, 1 Apr 2015 17:15:44 +0000
From: Itay Cnaan-On <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNOC - multiply TX and RX streams (multiple
block ports in a single RFNoC block to multiply)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I have a communication application which uses FMCW waveform for TX and the RX
is a backscatter reflections from some RFID.
The RX is de-mixed (multiplied) by a copy of the TX signal. Multiplication is
done in bandpass, then filtered and I am only interested in the baseband of the
de-mixing output for further data processing.
I would like to use the FPGA for this multiplication, in order to avoid
over-loading the host with a bandpass signal processing.
I couldn't find any computation engine in RFNOC that does that multiplication.
I therefore would like to use the NOC shell to create such block.
Questions:
1. Is there anyone who have tried something similar in RFNOC?
2. Can RFNOC support a block that handles two streams (RX and TX) as input
to same block?
3. The computation engine block ADDSUB operates on two streams. This seems
similar structure to what we need. Does it support RX and TX
addition/subtraction?
Thanks,
Itay
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/5ec6219d/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 01 Apr 2015 10:43:55 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RFNOC - multiply TX and RX streams (multiple
block ports in a single RFNoC block to multiply)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 01.04.2015 10:15, Itay Cnaan-On via USRP-users wrote:
> I couldn't find any computation engine in RFNOC that does that
> multiplication.
>
> I therefore would like to use the NOC shell to create such block.
>
>
> Questions:
>
> 1. Is there anyone who have tried something similar in RFNOC?
Not that I know of, which doesn't have to mean anything.
> 2. Can RFNOC support a block that handles two streams (RX and TX) as
> input to same block?
Yes, you can have up to 16 inputs per block.
> 3. The computation engine block ADDSUB operates on two streams. This
> seems similar structure to what we need. Does it support RX and TX
> addition/subtraction?
I'd like to advise some caution using the terms 'rx' and 'tx'. We use,
by convention, the host as reference, so data going host->usrp is
considered 'TX'. From this block's point of view, there's only input
streams and output streams. The fact that one of the input streams comes
from the radio is not really relevant here -- I'm sure you know all of
this, but I wanted to make sure all speak the same language.
A small thing on the side: You might want to delay the backscattered
signal given the amount of group delay the DSP paths introduce, but you
might also be able to calibrate this in software.
FMCW is actually a great application of RFNoC, since you handle large
bandwidths on the FPGA but can decimate rates before going to the host.
You can start with the AddSub block as a template.
I highly recommend starting with simulated backscatter during
development. So you create your FMCW signal (e.g. in GNU Radio), as well
as a backscattered version (i.e. attenuated, freq-shifted and delayed)
and send both those signals from the host to the RFNoC block on the
FPGA, then send the return signal back to the host. When the result
looks as expected, try with the radios.
You'll also need a splitstream block (already available) so you can tee
the signal (on the FPGA) both to the mixer block and the tx radio.
Cheers,
M
------------------------------
Message: 3
Date: Wed, 01 Apr 2015 10:47:53 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] 2 X310 motherboards with 4 channel receive
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Trek,
I'm not sure what your question is. In GRC, you'll get 4 fields for
frequencies, one for each channel, which you can fill within specs of
your daughterboards.
M
On 31.03.2015 12:22, Trek via USRP-users wrote:
> I need to set up 2 X310 motherboards to do a 4 channel receive using
> Gnuradio-Companion under Ubuntu 14.04 LTS,
> Under GRC, it seems not straighforward to specify the four different
> carrier frequencies (all four channels have different center freq).
> Pl. help.
>
> Thanks,
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Thu, 2 Apr 2015 02:04:47 +0800
From: "=?ISO-8859-1?B?VHJlaw==?=" <[email protected]>
To: "=?ISO-8859-1?B?TWFyY3VzIE38bGxlciB2aWEgVVNSUC11c2Vycw==?="
<[email protected]>,
"=?ISO-8859-1?B?TWFyY3VzIE38bGxlciB2aWEgVVNSUC11c2Vycw==?="
<[email protected]>
Subject: Re: [USRP-users] 2 X310 motherboards with 4 channel receive
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
thanks,problem solved.
------------------ Original ------------------
From: "Marcus M?ller via USRP-users";<[email protected]>;
Date: Apr 2, 2015
To: "usrp-users"<[email protected]>;
Subject: Re: [USRP-users] 2 X310 motherboards with 4 channel receive
Trek,
I'm not sure what your question is. In GRC, you'll get 4 fields for
frequencies, one for each channel, which you can fill within specs of
your daughterboards.
M
On 31.03.2015 12:22, Trek via USRP-users wrote:
> I need to set up 2 X310 motherboards to do a 4 channel receive using
> Gnuradio-Companion under Ubuntu 14.04 LTS,
> Under GRC, it seems not straighforward to specify the four different
> carrier frequencies (all four channels have different center freq).
> Pl. help.
>
> Thanks,
>
>
> _______________________________________________
> 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/20150402/8586a4d0/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 1 Apr 2015 19:50:31 +0000
From: Itay Cnaan-On <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNOC - rfnoc_adder example
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
We are trying to run the example that uses the ADDSUB block from gr_ettus.
When trying to run it, we get a message about not finding block AddSub_0:
Traceback (most recent call last):
File
"/home/usrp/Desktop/usrp_install/pybombs/pybombs/src/gr-ettus/examples/rfnoc/rfnoc_add_sub.py",
line 170, in <module>
tb = rfnoc_add_sub()
File
"/home/usrp/Desktop/usrp_install/pybombs/pybombs/src/gr-ettus/examples/rfnoc/rfnoc_add_sub.py",
line 83, in __init__
"AddSub", 0, -1,
File
"/home/usrp/Desktop/usrp_install/pybombs/target/lib/python2.7/dist-packages/ettus/ettus_swig.py",
line 2824, in make
return _ettus_swig.rfnoc_generic_make(*args, **kwargs)
RuntimeError: Cannot find a block for ID: AddSub_0
>>> Done (return code 1)
We suspect that the FPGA default RFNOC image does not have the AddSub block.
After installing it and running the probe command it gives the list of
supported blocks and AddSub is not one of them:
-- ========== Full list of RFNoC blocks: ============
-- * 0/Radio_0
-- * 0/Radio_1
-- * 0/VectorIIR_0
-- * 0/FIR_0
-- * 0/FFT_0
-- * 0/Window_0
-- * 0/FIFO_0
Are we missing something here?
Itay & Stewart
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/ef4f5655/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 1 Apr 2015 16:44:52 -0400
From: Raj Bhattacharjea <[email protected]>
To: [email protected]
Subject: [USRP-users] List valid subdev specs?
Message-ID:
<CAP3eQJcm_AshEkoHGm63fXGrmtqDkT05xr5asfHL6HF=r13...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have receiving application written in C++ where a user controls a B210
through a GUI. They enter parameters into the GUI (antenna port, gain,
center frequency, etc.) and hit "go", and the USRP responds and goes to
those settings. I do some input validation to make sure that their entries
aren't nonsense, and I check this by querying the multi_usrp API for valid
values (e.g., get_clock_sources, get_rx_freq_range, get_rx_gain_range, and
get_rx_antennas). If the entry is valid it's passed through to the
multi_usrp "setter" APIs, and if their inputs are invalid, I generally
default to the first valid value in the list of valid string values or clip
the numerical entries to the valid range.
However, there doesn't seem to be a high level API that returns all valid
subdevice specifications. Is this correct? So if the user enters "A:"
instead of "A:A", then I get an exception:
what(): AssertionError: assertion failed:
A: is not a valid rx subdevice specification on mboard 0.
possible values are: [A:A, A:B].
What I'd like to do instead is query UHD for the list of valid values (the
very list in the exception above), and if the user enters garbage, just
default to the first valid value in the list. Am I missing this API, or
does it really not exist? In the guts of the code there is
"validate_subdev_spec" which seems to do this checking, but the part that
generates the list of valid specifications uses the property tree APIs. Is
this functionality exposed up at the multi_usrp level?
--
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
http://www.prism.gatech.edu/~gtg037s/
404.894.7516
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/67de2aac/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 1 Apr 2015 13:56:27 -0700
From: Jonathon Pendlum <[email protected]>
To: Itay Cnaan-On <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC - rfnoc_adder example
Message-ID:
<cagdo0utm-jzfok0na09wssssutdtpp7ktey2vnadpy5uwlp...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Itay,
The X300 RFNoC FPGA image does not have as many computation engines
due the fact that the X300 FPGA has fewer resources than the X310
FPGA. One of the CEs not included is the AddSub block. You will need
to replace one of the included blocks in
usrp3/top/x300/rfnoc_auto_ce_inst_x300.v with the addsub block and
make a new FPGA image. Instructions for making images can be found in
the RFNoC Getting Started guide:
https://github.com/EttusResearch/uhd/wiki/RFNoC%3A-Getting-Started
Jonathon
On Wed, Apr 1, 2015 at 12:50 PM, Itay Cnaan-On via USRP-users
<[email protected]> wrote:
>
>
> Hi,
>
> We are trying to run the example that uses the ADDSUB block from gr_ettus.
> When trying to run it, we get a message about not finding block AddSub_0:
>
> Traceback (most recent call last):
> File
> "/home/usrp/Desktop/usrp_install/pybombs/pybombs/src/gr-ettus/examples/rfnoc/rfnoc_add_sub.py",
> line 170, in <module>
> tb = rfnoc_add_sub()
> File
> "/home/usrp/Desktop/usrp_install/pybombs/pybombs/src/gr-ettus/examples/rfnoc/rfnoc_add_sub.py",
> line 83, in __init__
> "AddSub", 0, -1,
> File
> "/home/usrp/Desktop/usrp_install/pybombs/target/lib/python2.7/dist-packages/ettus/ettus_swig.py",
> line 2824, in make
> return _ettus_swig.rfnoc_generic_make(*args, **kwargs)
> RuntimeError: Cannot find a block for ID: AddSub_0
>
>>>> Done (return code 1)
>
> We suspect that the FPGA default RFNOC image does not have the AddSub block.
> After installing it and running the probe command it gives the list of
> supported blocks and AddSub is not one of them:
>
> -- ========== Full list of RFNoC blocks: ============
> -- * 0/Radio_0
> -- * 0/Radio_1
> -- * 0/VectorIIR_0
> -- * 0/FIR_0
> -- * 0/FFT_0
> -- * 0/Window_0
> -- * 0/FIFO_0
>
>
> Are we missing something here?
>
> Itay & Stewart
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Wed, 01 Apr 2015 14:20:06 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] List valid subdev specs?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 01.04.2015 13:44, Raj Bhattacharjea via USRP-users wrote:
> What I'd like to do instead is query UHD for the list of valid values
> (the very list in the exception above), and if the user enters garbage,
> just default to the first valid value in the list. Am I missing this
> API, or does it really not exist? In the guts of the code there is
> "validate_subdev_spec" which seems to do this checking, but the part
> that generates the list of valid specifications uses the property tree
> APIs. Is this functionality exposed up at the multi_usrp level?
Good question, and no, we don't have a method to do exactly that.
However, when a device is initialized, it will set all available
channels as the default subdev spec (with one caveat, see below). So, if
you fire up a B210 and read back the subdev spec, you'll see "A:A A:B".
(USRP1 may be different).
The one caveat is that there are cases with multiple DDCs per channel,
so you can receive 2 channels on one d'board, and you'd have no way of
knowing this just from reading the default subdev spec.
One way to actually query possible specs is by parsing the property
tree, but you probably don't want to do that.
Cheers,
M
------------------------------
Message: 9
Date: Wed, 1 Apr 2015 17:57:24 -0400
From: Rob Kossler <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Rx/Tx Loopback
Message-ID:
<cab__htr5upzbkxeeyt5ksm0ywvs6g4l7d9d41ttbsvjppst...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I would like to run a simple Rx to Tx loopback using gnuradio companion
with my X310. The attached flowgraph contains two blocks, a UHD source and
UHD sink, which are directly connected to each other on each of the 2
channels.
When I run it, I get numerous "L" indications. To me, this indicates that
I'm not delivering the samples to the Tx Streamer when it wants them.
Perhaps the start times for RX streaming and TX streaming need to be
specified? If so, can this be done from GRC?
Thanks.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/3fb3c6ed/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx_rx_loopback.grc
Type: application/octet-stream
Size: 34071 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/3fb3c6ed/attachment-0001.grc>
------------------------------
Message: 10
Date: Wed, 1 Apr 2015 15:53:06 -0700
From: Richard Bell <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID:
<CAMMoi3tMdiCCS=+eqpdtjgscrksp3ocyucsrlepaqp1stzf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Rob,
If you attach a screenshot, as opposed to the actual grc file, you will get
a lot more people to look at it.
v/r,
Rich
On Wed, Apr 1, 2015 at 2:57 PM, Rob Kossler via USRP-users <
[email protected]> wrote:
> I would like to run a simple Rx to Tx loopback using gnuradio companion
> with my X310. The attached flowgraph contains two blocks, a UHD source and
> UHD sink, which are directly connected to each other on each of the 2
> channels.
>
> When I run it, I get numerous "L" indications. To me, this indicates that
> I'm not delivering the samples to the Tx Streamer when it wants them.
> Perhaps the start times for RX streaming and TX streaming need to be
> specified? If so, can this be done from GRC?
>
> Thanks.
> Rob
>
> _______________________________________________
> 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/20150401/d19219c9/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 2 Apr 2015 09:27:47 +0800
From: "=?ISO-8859-1?B?VHJlaw==?=" <[email protected]>
To: "=?ISO-8859-1?B?dXNycC11c2Vycw==?=" <[email protected]>
Subject: [USRP-users] Could this be Ettus X310 self jamming problem?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I am doing a spectrum analysis at 1.6 GHz with a Ettus X310 and
Gnuradio-compaion and UHD 3.8.2. The sampling frequency is 20MHz, and am seeing
a large spike at 1.6GHz with Gnuradio-companion, which I verified it is not in
the air with a real spectrum analyzer.
At first I suspect it is a ADC offset, but adjusting LO offset does not get it
go away. Could this be a self jamming issue in X310 at 1.6GHz, is there a way
to remedy this?
thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/857ad6e2/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 01 Apr 2015 22:58:14 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/01/2015 05:57 PM, Rob Kossler via USRP-users wrote:
> I would like to run a simple Rx to Tx loopback using gnuradio
> companion with my X310. The attached flowgraph contains two blocks, a
> UHD source and UHD sink, which are directly connected to each other on
> each of the 2 channels.
>
> When I run it, I get numerous "L" indications. To me, this indicates
> that I'm not delivering the samples to the Tx Streamer when it wants
> them. Perhaps the start times for RX streaming and TX streaming need
> to be specified? If so, can this be done from GRC?
>
> Thanks.
> Rob
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
The only thing I notice is that you've specified a really-low sample
rate, one which I'm thinking the X310 cannot support, did you get any
error messages
to that effect when it's running.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/db360d76/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 1 Apr 2015 23:00:31 -0400
From: Rob Kossler <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID:
<cab__htsu5xo-ei75a_tg+rsn+zmxx_pefcst14jn61udj2e...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I don't recall any error message with the low sample rate. But, I was also
using higher rates like 1 MS/s and 10 MS/s also.
Rob
On Wed, Apr 1, 2015 at 10:58 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 04/01/2015 05:57 PM, Rob Kossler via USRP-users wrote:
>
> I would like to run a simple Rx to Tx loopback using gnuradio companion
> with my X310. The attached flowgraph contains two blocks, a UHD source and
> UHD sink, which are directly connected to each other on each of the 2
> channels.
>
> When I run it, I get numerous "L" indications. To me, this indicates that
> I'm not delivering the samples to the Tx Streamer when it wants them.
> Perhaps the start times for RX streaming and TX streaming need to be
> specified? If so, can this be done from GRC?
>
> Thanks.
> Rob
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> The only thing I notice is that you've specified a really-low sample
> rate, one which I'm thinking the X310 cannot support, did you get any error
> messages
> to that effect when it's running.
>
>
> _______________________________________________
> 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/20150401/42fc9e8d/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 01 Apr 2015 23:04:09 -0400
From: "Marcus D. Leech" <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/01/2015 11:00 PM, Rob Kossler wrote:
> I don't recall any error message with the low sample rate. But, I was
> also using higher rates like 1 MS/s and 10 MS/s also.
> Rob
>
May just be a buffering elasticity issue.
Try putting something like a multiply-const block between them, with a
constant of 1.0. Just to put some buffering in place.
These streams are going to the same physical device, yes? And it has a
1PPS input?
> On Wed, Apr 1, 2015 at 10:58 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 04/01/2015 05:57 PM, Rob Kossler via USRP-users wrote:
>> I would like to run a simple Rx to Tx loopback using gnuradio
>> companion with my X310. The attached flowgraph contains two
>> blocks, a UHD source and UHD sink, which are directly connected
>> to each other on each of the 2 channels.
>>
>> When I run it, I get numerous "L" indications. To me, this
>> indicates that I'm not delivering the samples to the Tx Streamer
>> when it wants them. Perhaps the start times for RX streaming and
>> TX streaming need to be specified? If so, can this be done from GRC?
>>
>> Thanks.
>> Rob
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> The only thing I notice is that you've specified a really-low
> sample rate, one which I'm thinking the X310 cannot support, did
> you get any error messages
> to that effect when it's running.
>
>
> _______________________________________________
> 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/20150401/9e089b5d/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 1 Apr 2015 23:35:04 -0400
From: Rob Kossler <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID:
<CAB__hTTHJCZw59dd1jjxKUHMuer22zcZ+=k_u40xjevshp8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
ok. I'll try that. Thanks.
Yes, the streams are going to the same physical device. But no 1 PPS
input. My intention is to use X310 internal PPS. I think the GRC UHD
sink/source setting for clock source is "default". I'm assuming that means
internal PPS.
On Wed, Apr 1, 2015 at 11:04 PM, Marcus D. Leech <[email protected]> wrote:
> On 04/01/2015 11:00 PM, Rob Kossler wrote:
>
> I don't recall any error message with the low sample rate. But, I was
> also using higher rates like 1 MS/s and 10 MS/s also.
> Rob
>
> May just be a buffering elasticity issue.
>
> Try putting something like a multiply-const block between them, with a
> constant of 1.0. Just to put some buffering in place.
>
> These streams are going to the same physical device, yes? And it has a
> 1PPS input?
>
>
>
> On Wed, Apr 1, 2015 at 10:58 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 04/01/2015 05:57 PM, Rob Kossler via USRP-users wrote:
>>
>> I would like to run a simple Rx to Tx loopback using gnuradio
>> companion with my X310. The attached flowgraph contains two blocks, a UHD
>> source and UHD sink, which are directly connected to each other on each of
>> the 2 channels.
>>
>> When I run it, I get numerous "L" indications. To me, this indicates
>> that I'm not delivering the samples to the Tx Streamer when it wants them.
>> Perhaps the start times for RX streaming and TX streaming need to be
>> specified? If so, can this be done from GRC?
>>
>> Thanks.
>> Rob
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> The only thing I notice is that you've specified a really-low sample
>> rate, one which I'm thinking the X310 cannot support, did you get any error
>> messages
>> to that effect when it's running.
>>
>>
>> _______________________________________________
>> 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/20150401/46de524c/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 01 Apr 2015 23:38:07 -0400
From: "Marcus D. Leech" <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/01/2015 11:35 PM, Rob Kossler wrote:
> ok. I'll try that. Thanks.
>
>
> Yes, the streams are going to the same physical device. But no 1 PPS
> input. My intention is to use X310 internal PPS. I think the GRC UHD
> sink/source setting for clock source is "default". I'm assuming that
> means internal PPS.
>
>
> On Wed, Apr 1, 2015 at 11:04 PM, Marcus D. Leech <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 04/01/2015 11:00 PM, Rob Kossler wrote:
>> I don't recall any error message with the low sample rate. But,
>> I was also using higher rates like 1 MS/s and 10 MS/s also.
>> Rob
>>
> May just be a buffering elasticity issue.
>
> Try putting something like a multiply-const block between them,
> with a constant of 1.0. Just to put some buffering in place.
>
> These streams are going to the same physical device, yes? And it
> has a 1PPS input?
>
>
>
>> On Wed, Apr 1, 2015 at 10:58 PM, Marcus D. Leech via USRP-users
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> On 04/01/2015 05:57 PM, Rob Kossler via USRP-users wrote:
>>> I would like to run a simple Rx to Tx loopback using
>>> gnuradio companion with my X310. The attached flowgraph
>>> contains two blocks, a UHD source and UHD sink, which are
>>> directly connected to each other on each of the 2 channels.
>>>
>>> When I run it, I get numerous "L" indications. To me, this
>>> indicates that I'm not delivering the samples to the Tx
>>> Streamer when it wants them. Perhaps the start times for RX
>>> streaming and TX streaming need to be specified? If so, can
>>> this be done from GRC?
>>>
>>> Thanks.
>>> Rob
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> The only thing I notice is that you've specified a really-low
>> sample rate, one which I'm thinking the X310 cannot support,
>> did you get any error messages
>> to that effect when it's running.
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
YOu have "don't sync" on the sink, and "unknown PPS" on the source.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/fc943108/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 1 Apr 2015 23:38:58 -0400
From: Rob Kossler <[email protected]>
To: Richard Bell <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID:
<cab__htqwowhlyxx+cyw8sn85trhgee8bvtrtkwr4fpscaug...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Here is the screen shot.
On Wed, Apr 1, 2015 at 6:53 PM, Richard Bell <[email protected]>
wrote:
> Rob,
>
> If you attach a screenshot, as opposed to the actual grc file, you will
> get a lot more people to look at it.
>
> v/r,
> Rich
>
> On Wed, Apr 1, 2015 at 2:57 PM, Rob Kossler via USRP-users <
> [email protected]> wrote:
>
>> I would like to run a simple Rx to Tx loopback using gnuradio companion
>> with my X310. The attached flowgraph contains two blocks, a UHD source and
>> UHD sink, which are directly connected to each other on each of the 2
>> channels.
>>
>> When I run it, I get numerous "L" indications. To me, this indicates
>> that I'm not delivering the samples to the Tx Streamer when it wants them.
>> Perhaps the start times for RX streaming and TX streaming need to be
>> specified? If so, can this be done from GRC?
>>
>> Thanks.
>> Rob
>>
>> _______________________________________________
>> 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/20150401/1c92c65b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-04-01 23:36:49.png
Type: image/png
Size: 181577 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/1c92c65b/attachment-0001.png>
------------------------------
Message: 18
Date: Wed, 1 Apr 2015 23:41:12 -0400
From: Rob Kossler <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID:
<cab__htqeowm1cmgksrnarmwizxw4vfrggxskodw2q-nsohf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, Apr 1, 2015 at 11:38 PM, Marcus D. Leech <[email protected]> wrote:
> On 04/01/2015 11:35 PM, Rob Kossler wrote:
>
> ok. I'll try that. Thanks.
>
>
> Yes, the streams are going to the same physical device. But no 1 PPS
> input. My intention is to use X310 internal PPS. I think the GRC UHD
> sink/source setting for clock source is "default". I'm assuming that means
> internal PPS.
>
>
> On Wed, Apr 1, 2015 at 11:04 PM, Marcus D. Leech <[email protected]>
> wrote:
>
>> On 04/01/2015 11:00 PM, Rob Kossler wrote:
>>
>> I don't recall any error message with the low sample rate. But, I was
>> also using higher rates like 1 MS/s and 10 MS/s also.
>> Rob
>>
>> May just be a buffering elasticity issue.
>>
>> Try putting something like a multiply-const block between them, with a
>> constant of 1.0. Just to put some buffering in place.
>>
>> These streams are going to the same physical device, yes? And it has a
>> 1PPS input?
>>
>>
>>
>> On Wed, Apr 1, 2015 at 10:58 PM, Marcus D. Leech via USRP-users <
>> [email protected]> wrote:
>>
>>> On 04/01/2015 05:57 PM, Rob Kossler via USRP-users wrote:
>>>
>>> I would like to run a simple Rx to Tx loopback using gnuradio
>>> companion with my X310. The attached flowgraph contains two blocks, a UHD
>>> source and UHD sink, which are directly connected to each other on each of
>>> the 2 channels.
>>>
>>> When I run it, I get numerous "L" indications. To me, this indicates
>>> that I'm not delivering the samples to the Tx Streamer when it wants them.
>>> Perhaps the start times for RX streaming and TX streaming need to be
>>> specified? If so, can this be done from GRC?
>>>
>>> Thanks.
>>> Rob
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing
>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> The only thing I notice is that you've specified a really-low sample
>>> rate, one which I'm thinking the X310 cannot support, did you get any error
>>> messages
>>> to that effect when it's running.
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
> YOu have "don't sync" on the sink, and "unknown PPS" on the source.
>
>
> Yes, those are the sync options. Since there is only one device, I only
selected "unknown PPS" for one of the two streamers. Is that correct?
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/dd1296f2/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 01 Apr 2015 23:41:36 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/01/2015 11:38 PM, Rob Kossler via USRP-users wrote:
> Here is the screen shot.
>
> On Wed, Apr 1, 2015 at 6:53 PM, Richard Bell <[email protected]
> <mailto:[email protected]>> wrote:
>
> Rob,
>
> If you attach a screenshot, as opposed to the actual grc file, you
> will get a lot more people to look at it.
>
> v/r,
> Rich
>
I have to admit that I vastly prefer the .grc file--that way, I can open
it up, look at parameter settings in blocks, etc. A screenshot of the
flow-graph
tells only a small part of the story....
>
> On Wed, Apr 1, 2015 at 2:57 PM, Rob Kossler via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> I would like to run a simple Rx to Tx loopback using gnuradio
> companion with my X310. The attached flowgraph contains two
> blocks, a UHD source and UHD sink, which are directly
> connected to each other on each of the 2 channels.
>
> When I run it, I get numerous "L" indications. To me, this
> indicates that I'm not delivering the samples to the Tx
> Streamer when it wants them. Perhaps the start times for RX
> streaming and TX streaming need to be specified? If so, can
> this be done from GRC?
>
> Thanks.
> Rob
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/3916c3d2/attachment-0001.html>
------------------------------
Message: 20
Date: Wed, 01 Apr 2015 23:45:22 -0400
From: "Marcus D. Leech" <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/01/2015 11:41 PM, Rob Kossler wrote:
>
>
>
> Yes, those are the sync options. Since there is only one device, I
> only selected "unknown PPS" for one of the two streamers. Is that
> correct?
> Rob
That would be correct for a device that had 1PPS. I don't recall
whether X3xx has a "fake" internal 1PPS signal or not. Since this is a
single device
at this point, just choose "don't sync" for both of them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150401/62864627/attachment-0001.html>
------------------------------
Message: 21
Date: Thu, 2 Apr 2015 08:00:08 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: <[email protected]>, "'Ron Economos'" <[email protected]>
Subject: [USRP-users] DVB-x (was: Again performance issues B210, while
BladeRF performs fine)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
I adjusted the subject...
The issue with DVB-T were the 10 threads in FFT settings; reducing this to
one thread gives a stable and spectrum-wise OK looking signal, around 40dB
above noise when transmitted over a distance of one or two meters. So I took
my old laptop, went through the hassle installing a completely new Windows 7
and the DVB-T receiver stuff (DVBViewer and a RTL2832 based RX), and I was
able to find "something" on the chosen channel, with 55% signal strength, a
garbled channel name showed up, but no picture. At least somehow it looks
like a DVB-T signal, when I find some time I will try tweaking the settings
if I can get real reception. Oh, the receiver is OK, I can watch normal TV
with it, using just 15cm of wire as antenna. Next week I should have access
to a DVB-x antenna tester, maybe this beast can tell me more about the
signal.
What example with the supplied test.ts is recommended for being received
with a normal receiver?
Ralph.
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Ralph A. Schmid, dk5ras via USRP-users
> Sent: Wednesday, April 1, 2015 1:58 PM
> To: 'Ron Economos'
> Cc: 'usrp-users'
> Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
> performs fine
>
> I will give it a try later this evening, however from the first test in
the lunch
> break I found that DVB-T still produces lots of U, while DVB-T2 is stable.
I did
> not yet test DVB-S2, but this will be one of the next projects...
>
> Thanks a lot for all the assistance! It is amazing what you created with
all
> those TV mode projects!!
>
> Ralph.
>
> > -----Original Message-----
> > From: Ron Economos [mailto:[email protected]]
> > Sent: Tuesday, March 31, 2015 12:50 PM
> > To: Ralph A. Schmid, dk5ras
> > Cc: 'usrp-users'
> > Subject: Re: [USRP-users] Again performance issues B210, while BladeRF
> > performs fine
> >
> > 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
> > >>>>
> > >
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 22
Date: Thu, 2 Apr 2015 12:17:35 +0500
From: Amber and Sarosh <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Cloning E310 Firmware
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi
Can anyone please help us making an image of the E310 firmware with our custom
installations such that it can be burned as it is on an other device?
Regards,
Amber, Sarosh & Naheed
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/3ddf1301/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 02 Apr 2015 01:17:03 -0700
From: Ron Economos <[email protected]>
To: 'usrp-users' <[email protected]>
Subject: Re: [USRP-users] DVB-x (was: Again performance issues B210,
while BladeRF performs fine)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sorry for the late reply. Comcast blocks certain addresses
on re-mailers, and I missed your e-mail.
I have a bunch of DVB-T test streams on my website. They
are listed in this post on the Nuand forum.
http://nuand.com/forums/viewtopic.php?f=8&t=3499#p5124
Ron
Hi,
I adjusted the subject...
The issue with DVB-T were the 10 threads in FFT settings; reducing this to
one thread gives a stable and spectrum-wise OK looking signal, around 40dB
above noise when transmitted over a distance of one or two meters. So I took
my old laptop, went through the hassle installing a completely new Windows 7
and the DVB-T receiver stuff (DVBViewer and a RTL2832 based RX), and I was
able to find "something" on the chosen channel, with 55% signal strength, a
garbled channel name showed up, but no picture. At least somehow it looks
like a DVB-T signal, when I find some time I will try tweaking the settings
if I can get real reception. Oh, the receiver is OK, I can watch normal TV
with it, using just 15cm of wire as antenna. Next week I should have access
to a DVB-x antenna tester, maybe this beast can tell me more about the
signal.
What example with the supplied test.ts is recommended for being received
with a normal receiver?
Ralph.
------------------------------
Message: 24
Date: Thu, 2 Apr 2015 10:43:07 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] FW: DVB-x (was: Again performance issues B210,
while BladeRF performs fine)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
No problem, time is not an issue here.
I will have a look later and see if I find something that works.
Ralph, dk5ras :)
> > -----Original Message-----
> > From: USRP-users [mailto:[email protected]] On Behalf
> > Of Ron Economos via USRP-users
> > Sent: Thursday, April 2, 2015 10:17 AM
> > To: 'usrp-users'
> > Subject: Re: [USRP-users] DVB-x (was: Again performance issues B210,
> > while BladeRF performs fine)
> >
> > Sorry for the late reply. Comcast blocks certain addresses on
> > re-mailers, and I missed your e-mail.
> >
> > I have a bunch of DVB-T test streams on my website. They are listed in
> > this post on the Nuand forum.
> >
> > http://nuand.com/forums/viewtopic.php?f=8&t=3499#p5124
> >
> > Ron
> >
> > Hi,
> >
> > I adjusted the subject...
> >
> > The issue with DVB-T were the 10 threads in FFT settings; reducing
> > this to one thread gives a stable and spectrum-wise OK looking signal,
> > around 40dB above noise when transmitted over a distance of one or two
> > meters. So I took my old laptop, went through the hassle installing a
> > completely new Windows 7 and the DVB-T receiver stuff (DVBViewer and a
> > RTL2832 based RX), and I was able to find "something" on the chosen
> > channel, with 55% signal strength, a garbled channel name showed up,
> > but no picture. At least somehow it looks like a DVB-T signal, when I
> > find some time I will try tweaking the settings if I can get real
> > reception. Oh, the receiver is OK, I can watch normal TV with it,
> > using just 15cm of wire as antenna. Next week I should have access to
> > a DVB-x antenna tester, maybe this beast can tell me more about the
> signal.
> >
> > What example with the supplied test.ts is recommended for being
> > received with a normal receiver?
> >
> > Ralph.
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 25
Date: Thu, 02 Apr 2015 15:14:17 +0200
From: Piotr Krysik <[email protected]>
To: [email protected]
Subject: [USRP-users] Question: new (green) USRP B210 and Takachi
enclosure
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi all,
I wonder if Takachi enclosure MXA3-11-16 is suitable for USRP B210
revision 6?
If yes - is there design for drilling holes in the front and back of the
enclosure available?
Best Regards,
Piotr Krysik
------------------------------
Message: 26
Date: Thu, 02 Apr 2015 14:19:14 +0100
From: David <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Question: new (green) USRP B210 and Takachi
enclosure
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On 2015-04-02 14:14, Piotr Krysik via USRP-users wrote:
> Hi all,
>
> I wonder if Takachi enclosure MXA3-11-16 is suitable for USRP B210
> revision 6?
> If yes - is there design for drilling holes in the front and back of
> the
> enclosure available?
It doesn't directly answer your question, but an old reply of mine might
help you:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-February/012608.html
David
------------------------------
Message: 27
Date: Thu, 02 Apr 2015 15:32:47 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Question: new (green) USRP B210 and Takachi
enclosure
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi David,
http://files.ettus.com/b2x0_enclosure/
has plate masks available.
Greetings,
Marcus
On 04/02/2015 03:19 PM, David via USRP-users wrote:
> On 2015-04-02 14:14, Piotr Krysik via USRP-users wrote:
>> Hi all,
>>
>> I wonder if Takachi enclosure MXA3-11-16 is suitable for USRP B210
>> revision 6?
>> If yes - is there design for drilling holes in the front and back of the
>> enclosure available?
>
> It doesn't directly answer your question, but an old reply of mine
> might help you:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-February/012608.html
>
> David
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 28
Date: Thu, 02 Apr 2015 15:42:42 +0200
From: Piotr Krysik <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Question: new (green) USRP B210 and Takachi
enclosure
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
W dniu 02.04.2015 o 15:19, David via USRP-users pisze:
> On 2015-04-02 14:14, Piotr Krysik via USRP-users wrote:
>> Hi all,
>>
>> I wonder if Takachi enclosure MXA3-11-16 is suitable for USRP B210
>> revision 6?
>> If yes - is there design for drilling holes in the front and back of the
>> enclosure available?
>
> It doesn't directly answer your question, but an old reply of mine
> might help you:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-February/012608.html
>
> David
>
I've seen that post but I have following situation:
I'm in advanced talks with a company based in Poland regarding purchase
of 4 Takachi enclosures (with drilled holes and with printing) for B210
devices that we are going to buy. But I just figured out that Takachi
enclosures were advised for white USRPs B210 and there is no information
if the revision 6 devices will fit in it. I cannot find any drawing with
dimensions for drilling holes in the enclosure for revision 6 B210.
There is this file:
http://files.ettus.com/b2x0_enclosure/B210_PLATE_REV1.2_070913_FINAL2.pdf
but there are no dimensions.
Piotr
------------------------------
Message: 29
Date: Thu, 2 Apr 2015 21:45:16 +0800
From: "=?ISO-8859-1?B?VHJlaw==?=" <[email protected]>
To: "=?ISO-8859-1?B?TWFyY3VzIE38bGxlciB2aWEgVVNSUC11c2Vycw==?="
<[email protected]>
Subject: Re: [USRP-users] Could this be Ettus X310 self jamming
problem?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
the attached shows the spectrum at 1.6GHz from GRC.
------------------ Original ------------------
From: "Marcus M?ller via USRP-users";<[email protected]>;
Date: Thu, Apr 2, 2015 09:27 AM
To: "usrp-users"<[email protected]>;
Subject: [USRP-users] Could this be Ettus X310 self jamming problem?
I am doing a spectrum analysis at 1.6 GHz with a Ettus X310 and
Gnuradio-compaion and UHD 3.8.2. The sampling frequency is 20MHz, and am seeing
a large spike at 1.6GHz with Gnuradio-companion, which I verified it is not in
the air with a real spectrum analyzer.
At first I suspect it is a ADC offset, but adjusting LO offset does not get it
go away. Could this be a self jamming issue in X310 at 1.6GHz, is there a way
to remedy this?
thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/4f50d048/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-04-01 17:58:44.png
Type: application/octet-stream
Size: 160951 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/4f50d048/attachment-0001.png>
------------------------------
Message: 30
Date: Thu, 2 Apr 2015 16:12:37 +0200
From: Sylvain Munaut <[email protected]>
To: Trek <[email protected]>
Cc: Marcus M?ller via USRP-users <[email protected]>
Subject: Re: [USRP-users] Could this be Ettus X310 self jamming
problem?
Message-ID:
<CAHL+j08S7CNjV6Z_Z2vQad2K4abtzP-TTRNhUWW8g-KAJ=y...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> the attached shows the spectrum at 1.6GHz from GRC.
Can you redo the same and tune to 1.602 GHz ?
If the peak is still at 1.6 GHz, then we need to look for what's leaking there.
If it's now at 1.602 GHz, we need to look for why the DC cancellation
isn't working.
Cheers,
Sylvain
------------------------------
Message: 31
Date: Thu, 02 Apr 2015 16:15:16 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Could this be Ettus X310 self jamming
problem?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Trek,
which daughterboard is this?
Best regards,
Marcus
On 04/02/2015 03:45 PM, Trek via USRP-users wrote:
> the attached shows the spectrum at 1.6GHz from GRC.
>
> ------------------ Original ------------------
> *From: * "Marcus M?ller via USRP-users";<[email protected]>;
> *Date: * Thu, Apr 2, 2015 09:27 AM
> *To: * "usrp-users"<[email protected]>;
> *Subject: * [USRP-users] Could this be Ettus X310 self jamming problem?
>
> I am doing a spectrum analysis at 1.6 GHz with a Ettus X310 and
> Gnuradio-compaion and UHD 3.8.2. The sampling frequency is 20MHz, and
> am seeing a large spike at 1.6GHz with Gnuradio-companion, which I
> verified it is not in the air with a real spectrum analyzer.
>
> At first I suspect it is a ADC offset, but adjusting LO offset does
> not get it go away. Could this be a self jamming issue in X310 at
> 1.6GHz, is there a way to remedy this?
>
> thanks,
>
>
>
>
>
> _______________________________________________
> 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/20150402/9e923927/attachment-0001.html>
------------------------------
Message: 32
Date: Thu, 2 Apr 2015 22:16:51 +0800
From: "=?gb18030?B?VHJlaw==?=" <[email protected]>
To: "=?gb18030?B?U3lsdmFpbiBNdW5hdXQ=?=" <[email protected]>
Cc: Marcus M?ller via USRP-users <[email protected]>
Subject: [USRP-users] ??? Could this be Ettus X310 self jamming
problem?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gb18030"
I already did it at 1.602GHz instead of 1.6GHz, same thing except now the large
spike is -2MHz from 0.
------------------ ???? ------------------
???: "Sylvain Munaut";<[email protected]>;
????: 2015?4?2?(???) ??10:12
???: "Trek"<[email protected]>;
??: "Marcus M?ller via USRP-users"<[email protected]>;
??: Re: [USRP-users] Could this be Ettus X310 self jamming problem?
> the attached shows the spectrum at 1.6GHz from GRC.
Can you redo the same and tune to 1.602 GHz ?
If the peak is still at 1.6 GHz, then we need to look for what's leaking there.
If it's now at 1.602 GHz, we need to look for why the DC cancellation
isn't working.
Cheers,
Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/139523d5/attachment-0001.html>
------------------------------
Message: 33
Date: Thu, 2 Apr 2015 10:28:00 -0400
From: Rob Kossler <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID:
<CAB__hTTSdB8ach=qhp585jtp9lu5bbgrcno8ne6ryr5bpf5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, Apr 1, 2015 at 11:45 PM, Marcus D. Leech <[email protected]> wrote:
> On 04/01/2015 11:41 PM, Rob Kossler wrote:
>
>
>
>>
>> Yes, those are the sync options. Since there is only one device, I
> only selected "unknown PPS" for one of the two streamers. Is that correct?
> Rob
>
> That would be correct for a device that had 1PPS. I don't recall whether
> X3xx has a "fake" internal 1PPS signal or not. Since this is a single
> device
> at this point, just choose "don't sync" for both of them.
>
>
>
I tried "don't sync" for both as well as putting constant multiply blocks
in between the source / sink. Neither seems to fix my "Late" issue.
However, if I exit GRC and simply run benchmark_rate in full duplex, it has
no issues even at higher sample rates.
Attached are 3 files: the modified GRC flowgraph as well as two text files
showing the results obtained when running this flowgraph from GRC as
compared to running benchmark_rate. The flowgraph sample rate is 1 MS/s
while the benchmark_rate is running at 10 MS/s (BTW, it also runs fine at
1MS/s).
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/eeb23c94/attachment-0001.html>
-------------- next part --------------
crosshair@crosshair-HP-Z440:~$ benchmark_rate --tx_rate=10e6 --rx_rate=10e6
--channels="0,1"
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-131-gb850dfb5
Creating the usrp device with: ...
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Initializing clock and time using internal sources... done
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X310
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: CBX-120 RX
RX Channel: 1
RX DSP: 1
RX Dboard: B
RX Subdev: CBX-120 RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: CBX-120 TX
TX Channel: 1
TX DSP: 1
TX Dboard: B
TX Subdev: CBX-120 TX
Testing receive rate 10.000000 Msps on 2 channels
Testing transmit rate 10.000000 Msps on 2 channels
Benchmark rate summary:
Num received samples: 200023152
Num dropped samples: 0
Num overflows detected: 0
Num transmitted samples: 200230736
Num sequence errors: 0
Num underflows detected: 0
Done!
crosshair@crosshair-HP-Z440:~$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tx_rx_loopback.grc
Type: application/octet-stream
Size: 36317 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/eeb23c94/attachment-0001.grc>
-------------- next part --------------
<<< Welcome to GNU Radio Companion v3.7.6.1-128-g8a3ad1a5 >>>
<<DELETED CONTENT>>
Generating: "/home/crosshair/Documents/gnuradio/rx_tx_loopback.py"
Executing: "/home/crosshair/Documents/gnuradio/rx_tx_loopback.py"
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-131-gb850dfb5
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Initializing clock and time using internal sources... done
-- Tune Request: 2412.000000 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 2412.000000 MHz
-- RF LO Result: 2411.999389 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: -0.000611 MHz
-- DSP Result: -0.000610 MHz
-- Successfully tuned to 2412.000000 MHz
--
-- Tune Request: 2412.000000 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 2412.000000 MHz
-- RF LO Result: 2411.999389 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: -0.000611 MHz
-- DSP Result: -0.000610 MHz
-- Successfully tuned to 2412.000000 MHz
--
-- Tune Request: 2412.000000 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 2412.000000 MHz
-- RF LO Result: 2411.999389 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: 0.000611 MHz
-- DSP Result: 0.000610 MHz
-- Successfully tuned to 2412.000000 MHz
--
-- Tune Request: 2412.000000 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 2412.000000 MHz
-- RF LO Result: 2411.999389 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: 0.000611 MHz
-- DSP Result: 0.000610 MHz
-- Successfully tuned to 2412.000000 MHz
--
Using Volk machine: avx_64_mmx
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
------------------------------
Message: 34
Date: Thu, 2 Apr 2015 22:36:49 +0800
From: "=?utf-8?B?VHJlaw==?=" <[email protected]>
To: "=?utf-8?B?TWFyY3VzIE3DvGxsZXIgdmlhIFVTUlAtdXNlcnM=?="
<[email protected]>
Subject: [USRP-users] USRP source channel bandwidth setting with GRC
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I am using the GRC USRP source, wonder how could I set the RF front end
bandwidth on the USRP device. I have been trying ajusting the bandwidth
parameter but it did not seem to have any effect. The device I have X310
WBX-120.
The following is from GRC documentation but it is not very clear to me.
Bandwidth:
To use the default bandwidth filter setting, this should be zero. Only certain
subdevices have configurable bandwidth filters. See the daughterboard
application notes for possible configurations.
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/cf6fd163/attachment-0001.html>
------------------------------
Message: 35
Date: Thu, 02 Apr 2015 10:47:27 -0400
From: [email protected]
To: Trek <[email protected]>
Cc: Marcus M?ller via USRP-users <[email protected]>
Subject: Re: [USRP-users] USRP source channel bandwidth setting with
GRC
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
The CBX/WBX/SBX family have fixed baseband analog filters, that
guarantee Nyquist criterion is satisfied on all platforms they are used
on.
In most cases, this is more than adequate, when combined with the
extremely-good digital filtering that happens after the analog baseband
is sampled by the ADC, and processed by the DSP logic in the FPGA. The
only time this wouldn't be true is if you have closely-spaced signals
within the ADC passband that exceed the dynamic range of the ADC. In
that case, RF filtering might actually be vastly better.
On 2015-04-02 10:36, Trek via USRP-users wrote:
> I am using the GRC USRP source, wonder how could I set the RF front end
> bandwidth on the USRP device. I have been trying ajusting the bandwidth
> parameter but it did not seem to have any effect. The device I have X310
> WBX-120.
>
> The following is from GRC documentation but it is not very clear to me.
>
> Bandwidth:
> To use the default bandwidth filter setting, this should be zero. Only
> certain subdevices have configurable bandwidth filters. See the daughterboard
> application notes for possible configurations.
> ?
>
> _______________________________________________
> 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/20150402/8aaaf3e5/attachment-0001.html>
------------------------------
Message: 36
Date: Thu, 02 Apr 2015 10:51:48 -0400
From: [email protected]
To: Rob Kossler <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Well, I wonder if our gr-uhd maintainer has a comment.
This seems very odd to me, and perhaps there's a subtlety in the way
gr-uhd tries to be helpful and setup a bunch of stuff involving sample
timing automatically.
On 2015-04-02 10:28, Rob Kossler wrote:
> On Wed, Apr 1, 2015 at 11:45 PM, Marcus D. Leech <[email protected]> wrote:
>
> On 04/01/2015 11:41 PM, Rob Kossler wrote:
>
> Yes, those are the sync options. Since there is only one device, I only
> selected "unknown PPS" for one of the two streamers. Is that correct?
> Rob
That would be correct for a device that had 1PPS. I don't recall
whether X3xx has a "fake" internal 1PPS signal or not. Since this is a
single device
at this point, just choose "don't sync" for both of them.
I tried "don't sync" for both as well as putting constant multiply
blocks in between the source / sink. Neither seems to fix my "Late"
issue. However, if I exit GRC and simply run benchmark_rate in full
duplex, it has no issues even at higher sample rates.
Attached are 3 files: the modified GRC flowgraph as well as two text
files showing the results obtained when running this flowgraph from GRC
as compared to running benchmark_rate. The flowgraph sample rate is 1
MS/s while the benchmark_rate is running at 10 MS/s (BTW, it also runs
fine at 1MS/s).
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/3e54db74/attachment-0001.html>
------------------------------
Message: 37
Date: Thu, 2 Apr 2015 11:12:43 +0200
From: scott tiger <[email protected]>
To: [email protected]
Subject: [USRP-users] problem with MISO signal receiving
Message-ID:
<CA+Kb_uf37bVCqmaws7UQT8tNabgL_x9WvJ7yS7eckU=zwro...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
I am trying to send two orthogonal sequences from different antennas and
receive them in one (2 by 1) . I am using two USRP for transmitting purpose
synchronized using MIMO cable (with two antennas) and receive one signal
but when I check it it seems that all the orthogonality disappears. While
when I use SISO transmission I can receive a good signal. Can you please
help me in this problem? Can be this problem caused because of
unsynchronized receiver with the transmission part ?
Thank you for your help
Maksim Veronov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150402/c6af17d1/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 56, Issue 2
*****************************************
