We are using the delayed start capability of libuhd to control the time data
start streaming
from a B210 FPGA to the host PC and hence add custom tags in the IQ datastream
generated within
the FPGA.
Using the delayed start function seems to work fine with single channel
acquisition but we are
wo
Hi Jean-Michel,
On 07/07/21 12:07, frie...@free.fr wrote:
> why is the multichannel behaviour in a single receiver such as the B210
> different from the single
> channel streaming? I can imagine the different behaviour for networked
> multichannels USRP (e.g.
> X310) but how about the B210?
I
Hi all,
I get an undecipherable assertion failure when running the following
simple code using a 1Gbps Ethernet link. The error happens when t1 goes
out of scope, every time I run the application. What am I missing?
int main(int argc, char *argv[]) {
uhd::device_addr_t devAddresses("addr=
Dear USRP and GNURadio Community
I have 3 USRP X310 with two SBX-120 daughterboards installed. each of
USRPs has two dedicated 10GB Interface with host server.
I'm trying to build a synchronouse system which has 2 receiver and one
transmitter and Octoclock CDA-2990 is used to synch both clock
On 07/07/2021 09:36 AM, Armin Ghani wrote:
Dear USRP and GNURadio Community
I have 3 USRP X310 with two SBX-120 daughterboards installed. each of
USRPs has two dedicated 10GB Interface with host server.
I'm trying to build a synchronouse system which has 2 receiver and one
transmitter and O
Thanks Marcus for quick answer.
There are two status LEDs on the octoclock which turns on (for 10MHz
ref) and start to blinking (for 1PPS) after the flowgraph starts.
But I'll try to check it with Oscop as well.
What do you mean by not implemented? Do you mean it is not assembled on
USRP har
On 07/07/2021 10:38 AM, Armin Ghani wrote:
What do you mean by not implemented? Do you mean it is not assembled
on USRP hardware?
My recollection is that the "feature" was implemented originally, but it
was found to be a very poor reference clock, and I thought
(maybe I'm wrong) that late
On 07/07/2021 09:09 AM, Viktor Erdelyi wrote:
Hi all,
I get an undecipherable assertion failure when running the following
simple code using a 1Gbps Ethernet link. The error happens when t1
goes out of scope, every time I run the application. What am I missing?
int main(int argc, char *argv[
On 07/07/2021 08:49 AM, Cédric Hannotier via USRP-users wrote:
Hi Jean-Michel,
On 07/07/21 12:07, frie...@free.fr wrote:
why is the multichannel behaviour in a single receiver such as the B210
different from the single
channel streaming? I can imagine the different behaviour for networked
mul
I've just checked the reference source for all USRPs, both 10MHz and
1PPS are perfectly distributed on the octoclock output.
10MHz => 3.5V p-p
1PPS => 5V p-p
Regards.
On 7/7/21 16:43, Marcus D. Leech wrote:
On 07/07/2021 10:38 AM, Armin Ghani wrote:
What do you mean by not implemented? Do
On 07/07/2021 11:14 AM, Armin Ghani wrote:
I've just checked the reference source for all USRPs, both 10MHz and
1PPS are perfectly distributed on the octoclock output.
10MHz => 3.5V p-p
1PPS => 5V p-p
The next thing to check then is the cabling.
Regards.
On 7/7/21 16:43, Marcus D. Leec
I checked the signals at the cable end which attached to the USRP input
reference.
And all the cables are the same part number with same cable length. Is
there anything else to check?
On 7/7/21 17:16, Marcus D. Leech wrote:
On 07/07/2021 11:14 AM, Armin Ghani wrote:
I've just checked the r
On 07/07/2021 11:19 AM, Armin Ghani wrote:
I checked the signals at the cable end which attached to the USRP
input reference.
And all the cables are the same part number with same cable length. Is
there anything else to check?
Check each X310 individually to see if this affects only a sing
Hi Michael,
I obtained the necessary SFP+ optical adapters and now I am trying to
put uhd 3.13.1.0 on the N321s in order to use the WR synchronization.
Unfortunately, when I update the sd card image with 3.13.1.0 the N321
boots but the SFP0 and SFP1 do not go up. When I try to run
uhd_find_de
I finally caught the bug, I mistakenly swapped the REF and TRG ports and
one the USRPs couldnt lock to the reference.
Thanks for your support.
On 7/7/21 17:22, Marcus D. Leech wrote:
On 07/07/2021 11:19 AM, Armin Ghani wrote:
I checked the signals at the cable end which attached to the USRP
I was thinking it would turn out to be exactly that. I’m glad it was not more
serious.
Sent from my iPhone
> On Jul 7, 2021, at 11:58 AM, Armin Ghani wrote:
>
>
> I finally caught the bug, I mistakenly swapped the REF and TRG ports and one
> the USRPs couldnt lock to the reference.
>
> Th
Part of the good news there is I'm utilizing the full 200 Msps clock speed so
I've been skipping both duc on TX and ddc on RX, thus hopefully minimizing any
front end delays to be measured
I'm slightly confused about the Rx metadata portion: I know in the uhd
namespace there is the rx_metadata_
On 07/07/2021 02:34 PM, Wolsieffer, Carl L. ERDC-RDE-CRL-NH CIV wrote:
Part of the good news there is I'm utilizing the full 200 Msps clock speed so
I've been skipping both duc on TX and ddc on RX, thus hopefully minimizing any
front end delays to be measured
I'm slightly confused about the Rx
18 matches
Mail list logo
