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. N210 with openwebrx: 0-3MHz aliased to 22-25MHz? (Anders Wallin)
2. Asymmetry in achievable TX/RX rates (Stefano Bettelli)
3. Re: Asymmetry in achievable TX/RX rates ([email protected])
4. Re: Asymmetry in achievable TX/RX rates (Ian Buckley)
5. X310 - It is possible to feed samples from a file to the rx
chain? (Paolo Palana)
6. Re: X310 - It is possible to feed samples from a file to the
rx chain? (Stefano Bettelli)
7. Re: [RFNoC] FPGA image is 2 bytes larger than expected (Sam Carey)
8. Re: X310 - It is possible to feed samples from a file to the
rx chain? (Paolo Palana)
9. Re: X310 - It is possible to feed samples from a file to the
rx chain? (Jason Matusiak)
10. X310/UBX Retuning Performance (devin kelly)
11. Re: X310/UBX Retuning Performance (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Feb 2017 20:00:10 +0200
From: Anders Wallin <[email protected]>
To: [email protected]
Subject: [USRP-users] N210 with openwebrx: 0-3MHz aliased to 22-25MHz?
Message-ID:
<capnvnrwc8cazjnjm3nod+k3ycp+x9kmvqchxmpwz8ant4k4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I'm using an N210 with LFRX (direct sampling) and a simple gnu-radio graph
that writes IQ samples to a FIFO file.
Openwebrx reads that IQ file and has a web UI: http://194.100.49.156:8073
The sample rate is 25 MS/s of IQ centered at 12.51 MHz
I noticed that signals from around 0-3 MHz get aliased/mirrored up to 25-22
MHz.
There's an image with some notes here:
https://goo.gl/photos/cskjwtaqLj4skMCe9
Any ideas on what is causing this? There is a 10 MHz low-pass filter on the
LFRX input, and when the signal-generator sweeps above 25 MHz there is no
aliasing.
thanks,
Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170223/19060204/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 23 Feb 2017 19:02:44 +0000
From: Stefano Bettelli <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <1C28F8990859A84D809CFC7AB0D38942A84EBE@lhreml502-mbx>
Content-Type: text/plain; charset="us-ascii"
Hi,
We are still in the process of extracting maximum performance from our USRP
X310's, and we have a weird problem with transmission of data, which does not
appear while reading data. The USRP that I am considering has two 10G fibre
connections, and uses the XG FPGA firmware (we use the latest UHD, 3.10.1.1).
The software developed by us and the benchmark_rate example agree on both RX
and TX, so I will report only the results with the benchmark_rate. RX works
nicely, we have 800MB/s on each fibre:
./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2" --duration 30
--channel "0,1" --rx_otw sc16 --rx_cpu sc16 --rx_rate 200e6
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.001.001-release
[...]
Testing receive rate 200.000000 Msps on 2 channels
Benchmark rate summary:
Num received samples: 12000120052
Num dropped samples: 0
Num overflows detected: 0
Num transmitted samples: 0
Num sequence errors: 0
Num underflows detected: 0
Num late commands: 0
Num timeouts: 0
However, TX shows a lot of problems for rates larger that 50MS/s, for instance:
./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2" --duration 30
--channel "0,1" --tx_otw sc16 --tx_cpu sc16 --tx_rate 100e6
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.001.001-release
[...]
Testing transmit rate 100.000000 Msps on 2 channels
[... throws a lot of U's ...]
Benchmark rate summary:
Num received samples: 0
Num dropped samples: 0
Num overflows detected: 0
Num transmitted samples: 6013212352
Num sequence errors: 0
Num underflows detected: 18509
Num late commands: 0
Num timeouts: 0
Eventually there is transmission at 400MB/s on both fibres, but we lose the
initial part. Achieving tx_rate=200e6 does not work at all (the USRP stops
replying). By observing the threads with htop we see that one thread approaches
80-90% of CPU usage. By comparison with our program, where we can identify the
threads, I infer that it is the thread containing the tx_streamer->send() call;
this call seems to be very heavy. All this looks strange because the Ethernet
fibres are exactly the same, and the rest of the system seems to be configured
in the same way for RX and TX:
Both network interfaces have MTU=9000:
ifconfig | grep enp129 -A3
enp129s0f0 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2c
inet addr:192.168.40.1 Bcast:192.168.40.255 Mask:255.255.255.0
inet6 addr: fe80::ea4d:d0ff:fec5:1b2c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
--
enp129s0f1 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2d
inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0
inet6 addr: fe80::ea4d:d0ff:fec5:1b2d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
Both RX and TX have large network buffer sizes
sysctl -a | grep net.core.*mem_max
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
both RX and TX have the same number of descriptors (also on the other card):
ethtool -g enp129s0f0
Ring parameters for enp129s0f0:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 512
RX Mini: 0
RX Jumbo: 0
TX: 512
Interrupt coalescing seems not to be available on these cards. The server is
also quite powerful, 2xXeon with 48 cores in total, and 128GB of memory. Cores
run at at least 3GHz. Can you suggest any idea to help us debugging this
problem? Thanks in advance,
Best regards/Mit freundlichen Gruessen,
Stefano Bettelli
Senior research engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170223/9c5737af/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 23 Feb 2017 19:52:42 +0000 (UTC)
From: [email protected]
To: Stefano Bettelli <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Stefano,
I have always had problems with any Tx rates over 25 MSA/sec on the X310. I am
a bit different on windows using 3.9.5 HGS image, but nice 8 physical core xeon
at 3.5 GHz...
I have been told there is significantly less buffer space on the Tx side and
that is the major issue.
Not sure about the 3.10 series...
----- Original Message -----
From: "Stefano Bettelli via USRP-users" <[email protected]>
To: "usrp-users" <[email protected]>
Sent: Thursday, February 23, 2017 2:02:44 PM
Subject: [USRP-users] Asymmetry in achievable TX/RX rates
Hi,
We are still in the process of extracting maximum performance from our USRP
X310's, and we have a weird problem with transmission of data, which does not
appear while reading data. The USRP that I am considering has two 10G fibre
connections, and uses the XG FPGA firmware (we use the latest UHD, 3.10.1.1).
The software developed by us and the benchmark_rate example agree on both RX
and TX, so I will report only the results with the benchmark_rate. RX works
nicely, we have 800MB/s on each fibre:
./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2" --duration 30
--channel "0,1" --rx_otw sc16 --rx_cpu sc16 --rx_rate 200e6
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.001-release
[...]
Testing receive rate 200.000000 Msps on 2 channels
Benchmark rate summary:
Num received samples: 12000120052
Num dropped samples: 0
Num overflows detected: 0
Num transmitted samples: 0
Num sequence errors: 0
Num underflows detected: 0
Num late commands: 0
Num timeouts: 0
However, TX shows a lot of problems for rates larger that 50MS/s, for instance:
./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2" --duration 30
--channel "0,1" --tx_otw sc16 --tx_cpu sc16 --tx_rate 100e6
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.001-release
[?]
Testing transmit rate 100.000000 Msps on 2 channels
[? throws a lot of U?s ?]
Benchmark rate summary:
Num received samples: 0
Num dropped samples: 0
Num overflows detected: 0
Num transmitted samples: 6013212352
Num sequence errors: 0
Num underflows detected: 18509
Num late commands: 0
Num timeouts: 0
Eventually there is transmission at 400MB/s on both fibres, but we lose the
initial part. Achieving tx_rate=200e6 does not work at all (the USRP stops
replying). By observing the threads with htop we see that one thread approaches
80-90% of CPU usage. By comparison with our program, where we can identify the
threads, I infer that it is the thread containing the tx_streamer->send() call;
this call seems to be very heavy. All this looks strange because the Ethernet
fibres are exactly the same, and the rest of the system seems to be configured
in the same way for RX and TX:
Both network interfaces have MTU=9000:
ifconfig | grep enp129 -A3
enp129s0f0 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2c
inet addr:192.168.40.1 Bcast:192.168.40.255 Mask:255.255.255.0
inet6 addr: fe80::ea4d:d0ff:fec5:1b2c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
--
enp129s0f1 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2d
inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0
inet6 addr: fe80::ea4d:d0ff:fec5:1b2d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
Both RX and TX have large network buffer sizes
sysctl -a | grep net.core.*mem_max
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
both RX and TX have the same number of descriptors (also on the other card):
ethtool -g enp129s0f0
Ring parameters for enp129s0f0:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 512
RX Mini: 0
RX Jumbo: 0
TX: 512
Interrupt coalescing seems not to be available on these cards. The server is
also quite powerful, 2xXeon with 48 cores in total, and 128GB of memory. Cores
run at at least 3GHz. Can you suggest any idea to help us debugging this
problem? Thanks in advance,
Best regards/Mit freundlichen Gruessen,
Stefano Bettelli
Senior research engineer
_______________________________________________
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/20170223/f44c53e7/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 23 Feb 2017 12:05:27 -0800
From: Ian Buckley <[email protected]>
To: Stefano Bettelli <[email protected]>
Cc: "[email protected] USRP-users"
<[email protected]>
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Stefano
I'll take a stab at explaining the probable background on this. UHD uses credit
based flow control to avoid overflowing buffers in the USRP. When you prepare
to start a new TX operation the TX buffer inside the USRP is completely empty
and can fill at wire rate speed. At some point it may/will become full and at
this point the credit based flow control algorithm will pace the data over the
network such that it approximates the TX rate over the air (Which is hard real
time). When the actual TX over the air operation starts relative to when the
buffering of data commences can yield some challenging situations.
If the TX operation starts as soon as the first samples of data reach the TX
DSP (i.e buffer is practically empty) then it runs the very real risk of
underflowing because it consumes data at a constant rate but data delivered
from the host tends to be bursty and jitter in delivery (since the host is
non-realtime in design) and also the main sample buffer is a DRAM with a single
port to which access is arbitrated adding more jitter as ingress and egress
compete for access. Typically UHD deals with the "buffer practically empty"
case by starting streaming the data to the USRP well in advance of a scheduled
TX operation start time allowing time for buffers to fill somewhat, but the
buffer access arbitration is tricky at startup since you have a corner case
situation with data streaming in at wire speeds rather than rate limited by the
credit algorithm plus data being drained at the configured sample rate by the
TX DSP. What you are probably therefore seeing is underflows (@ the DSP) dur
ing the initial fill of the buffer as internal bandwidth is transiently
exceeded, and then smoother operation as the bit rate over the network drops
back to approximate the transmission sample rate once the buffer is full.
I'm a couple of years stale on the internal implementation details of this now,
but that is the gist of the challenge.
-Ian
On Feb 23, 2017, at 11:02 AM, Stefano Bettelli via USRP-users
<[email protected]> wrote:
> Hi,
>
> We are still in the process of extracting maximum performance from our USRP
> X310's, and we have a weird problem with transmission of data, which does not
> appear while reading data. The USRP that I am considering has two 10G fibre
> connections, and uses the XG FPGA firmware (we use the latest UHD, 3.10.1.1).
> The software developed by us and the benchmark_rate example agree on both RX
> and TX, so I will report only the results with the benchmark_rate. RX works
> nicely, we have 800MB/s on each fibre:
>
> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2" --duration 30
> --channel "0,1" --rx_otw sc16 --rx_cpu sc16 --rx_rate 200e6
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.010.001.001-release
> [...]
> Testing receive rate 200.000000 Msps on 2 channels
> Benchmark rate summary:
> Num received samples: 12000120052
> Num dropped samples: 0
> Num overflows detected: 0
> Num transmitted samples: 0
> Num sequence errors: 0
> Num underflows detected: 0
> Num late commands: 0
> Num timeouts: 0
>
> However, TX shows a lot of problems for rates larger that 50MS/s, for
> instance:
>
> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2" --duration 30
> --channel "0,1" --tx_otw sc16 --tx_cpu sc16 --tx_rate 100e6
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.010.001.001-release
> [?]
> Testing transmit rate 100.000000 Msps on 2 channels
> [? throws a lot of U?s ?]
> Benchmark rate summary:
> Num received samples: 0
> Num dropped samples: 0
> Num overflows detected: 0
> Num transmitted samples: 6013212352
> Num sequence errors: 0
> Num underflows detected: 18509
> Num late commands: 0
> Num timeouts: 0
>
> Eventually there is transmission at 400MB/s on both fibres, but we lose the
> initial part. Achieving tx_rate=200e6 does not work at all (the USRP stops
> replying). By observing the threads with htop we see that one thread
> approaches 80-90% of CPU usage. By comparison with our program, where we can
> identify the threads, I infer that it is the thread containing the
> tx_streamer->send() call; this call seems to be very heavy. All this looks
> strange because the Ethernet fibres are exactly the same, and the rest of the
> system seems to be configured in the same way for RX and TX:
>
> Both network interfaces have MTU=9000:
> ifconfig | grep enp129 -A3
> enp129s0f0 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2c
> inet addr:192.168.40.1 Bcast:192.168.40.255 Mask:255.255.255.0
> inet6 addr: fe80::ea4d:d0ff:fec5:1b2c/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
> --
> enp129s0f1 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2d
> inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0
> inet6 addr: fe80::ea4d:d0ff:fec5:1b2d/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>
> Both RX and TX have large network buffer sizes
> sysctl -a | grep net.core.*mem_max
> net.core.rmem_max = 33554432
> net.core.wmem_max = 33554432
>
> both RX and TX have the same number of descriptors (also on the other card):
> ethtool -g enp129s0f0
> Ring parameters for enp129s0f0:
> Pre-set maximums:
> RX: 4096
> RX Mini: 0
> RX Jumbo: 0
> TX: 4096
> Current hardware settings:
> RX: 512
> RX Mini: 0
> RX Jumbo: 0
> TX: 512
>
> Interrupt coalescing seems not to be available on these cards. The server is
> also quite powerful, 2xXeon with 48 cores in total, and 128GB of memory.
> Cores run at at least 3GHz. Can you suggest any idea to help us debugging
> this problem? Thanks in advance,
>
> Best regards/Mit freundlichen Gruessen,
>
> Stefano Bettelli
> Senior research engineer
>
> _______________________________________________
> 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/20170223/6fee2e05/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 24 Feb 2017 10:13:41 +0100
From: Paolo Palana <[email protected]>
To: [email protected]
Subject: [USRP-users] X310 - It is possible to feed samples from a
file to the rx chain?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
I've a reference signal stored on a file, and I would ask if it is
possible to feed it directly to the rx chain through ethernet (or in
some other way). I'm working on a X310.
Thank you in advance
Paolo
------------------------------
Message: 6
Date: Fri, 24 Feb 2017 13:12:16 +0000
From: Stefano Bettelli <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 - It is possible to feed samples from a
file to the rx chain?
Message-ID: <1C28F8990859A84D809CFC7AB0D38942A84F05@lhreml502-mbx>
Content-Type: text/plain; charset="us-ascii"
Hi Paolo,
I assume you mean the TX chain here.
If you download the UHD source distribution there is an example directory.
You can compile the example named "tx_samples_from_file.cpp".
Cheers,
Stefano
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of Paolo
Palana via USRP-users
Sent: Freitag, 24. Februar 2017 10:14
To: [email protected]
Subject: [USRP-users] X310 - It is possible to feed samples from a file to the
rx chain?
Hi,
I've a reference signal stored on a file, and I would ask if it is possible to
feed it directly to the rx chain through ethernet (or in some other way). I'm
working on a X310.
Thank you in advance
Paolo
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Fri, 24 Feb 2017 09:27:58 -0500
From: Sam Carey <[email protected]>
To: [email protected], "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] [RFNoC] FPGA image is 2 bytes larger than
expected
Message-ID:
<cap85vd9kjhwuo5f_sk-_1xhv4_lf5p1nvabcactc28d-vtn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Howdy,
I had this problem a while back. My workaround was to simply edit the image
loader code so that it is OK with the larger file size.
Just do a search for the smaller byte number in the uhd/host source code,
change it to the larger byte number, and rebuild/reinstall uhd.
Apparently, the byte count is not a strict requirement for image loading.
You're the second other person I've seen with this problem.
Maybe somebody could apply this change to the main branch or something?
-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170224/14e2ae2d/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 24 Feb 2017 17:09:51 +0100
From: Paolo Palana <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310 - It is possible to feed samples from a
file to the rx chain?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 02/24/2017 02:12 PM, Stefano Bettelli via USRP-users wrote:
> Hi Paolo,
>
> I assume you mean the TX chain here.
Hi Stefano,
First of all thank you for your reply.
What really I mean is exactly the rx chain.
I'll try to explain me better.
Let us take into account the real case scenario where we have:
RX Antenna ----> RX analog frontend --> (ettus) DDC block --> my block --> to
host computer (eth)
Now what I'm asking for is a way to do something like that
RX Antenna ----> RX analog frontend --> (ettus) DDC block + -->
my block --> to host computer (eth)
|
HOST computer
-----------------------------------------------+
(hosting my reference signal)
> If you download the UHD source distribution there is an example directory.
> You can compile the example named "tx_samples_from_file.cpp".
> Cheers,
> Stefano
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Paolo Palana via USRP-users
> Sent: Freitag, 24. Februar 2017 10:14
> To: [email protected]
> Subject: [USRP-users] X310 - It is possible to feed samples from a file to
> the rx chain?
>
> Hi,
> I've a reference signal stored on a file, and I would ask if it is possible
> to feed it directly to the rx chain through ethernet (or in some other way).
> I'm working on a X310.
>
> Thank you in advance
>
> Paolo
>
> _______________________________________________
> 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
------------------------------
Message: 9
Date: Fri, 24 Feb 2017 11:35:05 -0500
From: Jason Matusiak <[email protected]>
To: [email protected], Paolo Palana <[email protected]>
Subject: Re: [USRP-users] X310 - It is possible to feed samples from a
file to the rx chain?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Paolo,
I may be oversimplifying this, but would a file-source block work for
you? I currently have a known-signal that is saved in a file that I use
to test out my custom RFNoC blocks, it seems to work pretty well (just
remember to add a throttle since you aren't using the radio front-end
anymore).
On 02/24/2017 11:09 AM, Paolo Palana via USRP-users wrote:
> On 02/24/2017 02:12 PM, Stefano Bettelli via USRP-users wrote:
>> Hi Paolo,
>>
>> I assume you mean the TX chain here.
>
> Hi Stefano,
> First of all thank you for your reply.
> What really I mean is exactly the rx chain.
>
> I'll try to explain me better.
> Let us take into account the real case scenario where we have:
>
>
>
> RX Antenna ----> RX analog frontend --> (ettus) DDC block --> my block --> to
> host computer (eth)
>
>
> Now what I'm asking for is a way to do something like that
>
>
> RX Antenna ----> RX analog frontend --> (ettus) DDC block + -->
> my block --> to host computer (eth)
>
> |
> HOST computer
> -----------------------------------------------+
> (hosting my reference signal)
>
>
>
>
>> If you download the UHD source distribution there is an example directory.
>> You can compile the example named "tx_samples_from_file.cpp".
>> Cheers,
>> Stefano
>>
>> -----Original Message-----
>> From: USRP-users [mailto:[email protected]] On Behalf Of
>> Paolo Palana via USRP-users
>> Sent: Freitag, 24. Februar 2017 10:14
>> To: [email protected]
>> Subject: [USRP-users] X310 - It is possible to feed samples from a file to
>> the rx chain?
>>
>> Hi,
>> I've a reference signal stored on a file, and I would ask if it is possible
>> to feed it directly to the rx chain through ethernet (or in some other way).
>> I'm working on a X310.
>>
>> Thank you in advance
>>
>> Paolo
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 10
Date: Fri, 24 Feb 2017 11:41:21 -0500
From: devin kelly <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] X310/UBX Retuning Performance
Message-ID:
<caanlyub+sozemsv-gnmovyjhtownwpsjcjy7rnfwdefjms_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I'm interested in building a frequency hopping transceiver. Right now I'm
just try to figure out how fast I can hop using the X310 with a UBX.
Suppose I have to retune the daughtercard after every burst (like I want to
hop over a bandwidth that's wider than 160 MHZ - the max instantaneous
bandwidth the UBX supports). How fast can I retune the UBX transmitter?
What if I interleave two transmitters that alternate every burst? This
option should just cut the retune time in half, right?
I haven't been able to find much data about this for the X310/UBX on the
Ettus website or mailing list. I definitely appreciate any help or data
anyone has.
Devin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170224/01b434e3/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 24 Feb 2017 17:59:11 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310/UBX Retuning Performance
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Devin,
> How fast can I retune the UBX transmitter?
I've made a very rough run-down of things in
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-May/020156.html
It's really just an upper-boundary estimate. In fact, the time an LO
takes to retune depends on when you define it's finished doing that, ie.
after which time you consider the PLL to be stable enough for operation.
If you can live with frequency oscillations, you can work with the
signal earlier!
> What if I interleave two transmitters that alternate every burst?
> This option should just cut the retune time in half, right?
Yep! Also, shameless plug: The TwinRX daughterboard has two independent
frontends, so you get four 80 MHz RX bandwidths per X3x0 + 2x TwinRX,
instead of two 160 MHz RX bandwidths with X3x0 + 2x UBX160.
Best regards,
Marcus
On 02/24/2017 05:41 PM, devin kelly via USRP-users wrote:
> Hello,
>
> I'm interested in building a frequency hopping transceiver. Right now
> I'm just try to figure out how fast I can hop using the X310 with a UBX.
>
> Suppose I have to retune the daughtercard after every burst (like I
> want to hop over a bandwidth that's wider than 160 MHZ - the max
> instantaneous bandwidth the UBX supports). How fast can I retune the
> UBX transmitter? What if I interleave two transmitters that alternate
> every burst? This option should just cut the retune time in half, right?
>
> I haven't been able to find much data about this for the X310/UBX on
> the Ettus website or mailing list. I definitely appreciate any help
> or data anyone has.
>
> Devin
>
>
> _______________________________________________
> 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/20170224/b04169ae/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 78, Issue 22
******************************************
