[USRP-users] Using both TX/RX and RX2 ports on the same daughter board to receive signal simultaneously

[Karan Suri via USRP-users]

Hi,
I'm trying to using both TX/RX and RX2 ports on the same daughter board of
X310 to receive signal at the same time.
On the host side, I tried to create a new recv_to_file thread inside the
main thread(which will execute another recv_to_file). However, the terminal
will show the error "0/Radio_0 output port 0 is already connected".
What should I do if I want to set both antennas to be receiving antennas on
the host side?

Thanks,
Yue
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N210 - pure (real) 50MHz sine output

[Marcus Müller via USRP-users]

Hi Alex,

your application sounds cool :)

So, amplitude stability over ten seconds isn't usually a design goal –
how strong are these amplitude modulations?

Also, I'd have a standard visualization that I'd usually share here:

offset tuning

$f_\text{RF}$ is the frequency of the actual (physical) LO on the
daughterboard, whilst $f_\text{offset}$, as you've guessed, is done by
multiplying the data stream (after interpolation to the 100 MHz master
clock rate) with a "digital"
$e^{j2\pi\frac{f_\text{offset}}{\SI{100}{\mega\hertz}}}$ in the FPGA,
before giving it to the DAC.

Now, that "digital mixer" is implemented using a  CORDIC with an
inherently limited phase accumulator bit width – I'd see a reason for
that to experience some inaccuracy, but that would look more like a
millihertz frequency offset, I guess.

Also, note that I'm assuming you're either Using a UBX or WBX
daughterboard – as far as I know from the top of my head, these are the
only two that actually go down to 50 MHz. Maybe, on the other hand,
you're using a BasicTX or LFTX instead – in that case, there's no LO, so
$f_\text{RF}\equiv 0$. So: what daughterboard /are/ you using?

Best regards,
Marcus

On 02.08.2017 23:33, Alex Pesch via USRP-users wrote:
> ​Hello - 
>
> I'm attempting to use my N210 in a somewhat unconventional application
> that requires a pure (real) sine wave output, with some frequency
> modulation around 50MHz. This signal will be used to resonate a
> physical device within a small band around 50MHz. 
>
> H​owever, I'm finding when the center frequency is set to 50MHz, and I
> monitor the resulting waveform on an oscilloscope, I get a 50MHz tone
> that is slowly amplitude modulated (within a ~0.1 Hz envelope). This
> behavior does not occur when I set the center frequency to 0Hz, and
> feed in an arbitrary intermediate frequency... Unfortunately, I cannot
> use this technique to achieve a 50MHz output frequency due to
> bandwidth limitations.  
>
> I suspect the LO is getting set such that there is some time-variant
> phase offset being introduced (rounding error?), but am unfamiliar
> with the internals of the device. 
>
> Any tips/suggestions would be appreciated - I would like the RF output
> to simply resemble that of a signal generator at 50MHz. 
>
> Thanks in advance, 
> -Alex
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC:Delay block?

[Nick Foster via USRP-users]

I made one for a project, but can't share it as it's customer work. It's a
little bit tricky and I never got it 100% right, but it works well enough
for what it needs to do. The tricky parts are preserving or reconstituting
packet boundaries, and being able to advance and delay the stream without
blocking downstream (or upstream) blocks.

--n

On Wed, Aug 2, 2017 at 2:06 PM Dixon, James L via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I am wondering if there is some type of variable delay block available in
> RFNoC.  I see that there is a Delay block available in gnu-radio, but I
> need it to be in the FPGA.
>
> Thanks,
>
> Jim
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] N210 - pure (real) 50MHz sine output

[Alex Pesch via USRP-users]

​Hello -

I'm attempting to use my N210 in a somewhat unconventional application that
requires a pure (real) sine wave output, with some frequency modulation
around 50MHz. This signal will be used to resonate a physical device within
a small band around 50MHz.

H​owever, I'm finding when the center frequency is set to 50MHz, and I
monitor the resulting waveform on an oscilloscope, I get a 50MHz tone that
is slowly amplitude modulated (within a ~0.1 Hz envelope). This behavior
does not occur when I set the center frequency to 0Hz, and feed in an
arbitrary intermediate frequency... Unfortunately, I cannot use this
technique to achieve a 50MHz output frequency due to bandwidth limitations.


I suspect the LO is getting set such that there is some time-variant phase
offset being introduced (rounding error?), but am unfamiliar with the
internals of the device.

Any tips/suggestions would be appreciated - I would like the RF output to
simply resemble that of a signal generator at 50MHz.

Thanks in advance,
-Alex
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] C++ --> GRC(Socket PDU ---> QT Frequency GUI)

[Marcus Müller via USRP-users]

Hi Jack,

PDUs are not just samples one after the other – they contain metadata. I
can't really imagine what your flow graph looks like, so I'd be grateful
for a screenshot (File->Screen Capture).

Anyway, there'd be no obvious reason your UDP detour would make things
faster – maybe the intermediate socket buffering might help, but you'd
probably get the same result by extending a UHD USRP Source's Output
Buffer Size.

So, I'm not sure where we should take this – from a gut feeling, we
should maybe move on to the discuss-gnuradio mailing list and discuss
what part in your GNU Radio application isn't performing well enough –
as I'm currently assuming your approach wasn't born through an in-depth
analysis, but might more be of a trial iteration?

Best regards,

Marcus


On 02.08.2017 13:10, Jack White via USRP-users wrote:
> Hi,
>
> I've been having some difficulty getting reliable data flow from my
> USRP X310 with a GRC flowgraph, so I'm trying out writing my system in
> C++ with the UHD driver API. My first step has been to retrieve
> samples from the X310, forward them to a UDP port and then pick them
> up with a GRC Socket PDU component and then plot them. The C++
> programme, so far, follows Ettus's example rx_samples_to_udp almost
> exactly and uses the std::complex data type.
>
> When the data enters the running flowgraph from the UDP transport, I
> get this error:
>
> thread[thread-per-block[1]: ]: freq_sink_c:
> unknown data type of samples; must be complex.
>
> Can anyone offer insight into why this should occur?
>
> Many thanks,
>
> -- 
> Jack White
> white.n.j...@googlemail.com 
> 07875 813 745
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Support with UHD C++ API

[Karan Suri via USRP-users]

For minimum data loss at 50MSps, you have to use a 10G cable ,
Data rate with 1G is limited to ~33 MSps which rounds off to 28 MSps
(integral decimation).

Karan Suri
University of Michigan

On Aug 2, 2017 3:56 PM, "Derek Kozel via USRP-users" <
usrp-users@lists.ettus.com> wrote:

> Hello Snehasish,
>
> The UHD examples contain all the code to receive a stream of samples at
> that rate. What have you tried? We may be able to help better if you
> explain what is not working. 50 MS/s is not too high of a load so most
> recent computers should have no problem receiving that much data over a 10
> Gigabit Ethernet connection.
> https://github.com/EttusResearch/uhd/tree/maint/host/examples
>
> Regards,
> Derek
>
> On Wed, Aug 2, 2017 at 8:39 PM, Snehasish Kar via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello
>>
>>
>> I am trying to receive the entire 25MHz gsm signal using usrp x310 at an
>> sample rate of 50MSPS, which i need to receive in the host and send to the
>> GPU for demodulation. Please help me how to implement this with minimum
>> data loss.
>>
>>
>> BR
>>
>> Snehasish
>>
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC:Delay block?

[Dixon, James L via USRP-users]

Hi,

I am wondering if there is some type of variable delay block available in 
RFNoC.  I see that there is a Delay block available in gnu-radio, but I need it 
to be in the FPGA.

Thanks,

Jim

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] C++ --> GRC(Socket PDU ---> QT Frequency GUI)

[Jack White via USRP-users]

Hi,

I've been having some difficulty getting reliable data flow from my USRP
X310 with a GRC flowgraph, so I'm trying out writing my system in C++ with
the UHD driver API. My first step has been to retrieve samples from the
X310, forward them to a UDP port and then pick them up with a GRC Socket
PDU component and then plot them. The C++ programme, so far, follows
Ettus's example rx_samples_to_udp almost exactly and uses the
std::complex data type.

When the data enters the running flowgraph from the UDP transport, I get
this error:

thread[thread-per-block[1]: ]: freq_sink_c: unknown
data type of samples; must be complex.

Can anyone offer insight into why this should occur?

Many thanks,

-- 
Jack White
white.n.j...@googlemail.com
07875 813 745
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Support with UHD C++ API

[Derek Kozel via USRP-users]

Hello Snehasish,

The UHD examples contain all the code to receive a stream of samples at
that rate. What have you tried? We may be able to help better if you
explain what is not working. 50 MS/s is not too high of a load so most
recent computers should have no problem receiving that much data over a 10
Gigabit Ethernet connection.
https://github.com/EttusResearch/uhd/tree/maint/host/examples

Regards,
Derek

On Wed, Aug 2, 2017 at 8:39 PM, Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello
>
>
> I am trying to receive the entire 25MHz gsm signal using usrp x310 at an
> sample rate of 50MSPS, which i need to receive in the host and send to the
> GPU for demodulation. Please help me how to implement this with minimum
> data loss.
>
>
> BR
>
> Snehasish
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Support with UHD C++ API

[Snehasish Kar via USRP-users]

Hello


I am trying to receive the entire 25MHz gsm signal using usrp x310 at an sample 
rate of 50MSPS, which i need to receive in the host and send to the GPU for 
demodulation. Please help me how to implement this with minimum data loss.


BR

Snehasish

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Brench Maint and Master of UHD

[Nate Temple via USRP-users]

Hi Daniele,

Generally speaking, 'maint' should be stable. 

If you need an absolutely stable version, it is recommended to use a tagged 
release, such as 'release_003_010_002_000' (UHD 3.10.2.0) or 
'release_003_009_007' (UHD 3.9.7). We perform release testing on every tagged 
version of UHD. Unless you need a specific fix or feature that may be on 
'maint' or 'master', it's generally best to use to most recent tagged release 
of UHD. 

Which warnings did you get during your build?

Regards,
Nate Temple


> On Jul 26, 2017, at 3:02 PM, Disco Daniele via USRP-users 
>  wrote:
> 
> HI!
> Building from source the library UHD, for the branch maint (that is reported 
> is a stable version) I obtained some warnings (during the compilation) for 
> the master no.
> (I have verified this in a virtual machine that i've rebuilt for "snapshot" 
> trouble but I can rebuilt again the maint version  if it is necessary).
> The question is "it is always true the the stable version in the Maint 
> branch?"
> Thank you
> Daniele   
>  
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle 
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante 
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora 
> abbiate ricevuto questo documento per errore siete cortesemente pregati di 
> darne immediata comunicazione al mittente e di provvedere alla sua 
> distruzione, Grazie. 
> 
> This e-mail and any attachments is confidential and may contain privileged 
> information intended for the addressee(s) only. Dissemination, copying, 
> printing or use by anybody else is unauthorised. If you are not the intended 
> recipient, please delete this message and any attachments and advise the 
> sender by return e-mail, Thanks. 
> 
> Rispetta l'ambiente. Non stampare questa mail se non è necessario.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] doubts about burst tranmission using tag SOB and EOB

[Yang Liu via USRP-users]

Dear all,

I tried to achieve burst transmission on usrp X310, the brief tx flowgraph
is in the below:

message_burst_source -> signal processing blocks --> usrp_sink

New message will be inserted into the message queue of message_burst_source.

Since message_burst_source will attach SOB and EOB tag to the data stream,
usrp will know the start and end of each burst. After reading 'Busrt
Transmission' section in this link:
https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html, my
understanding is that because of these two tags, even the two message
arrives at usrp at a different time, usrp will not complain about underrun.
However, according to results from my experiments, as the time difference
between two contiguous message increases, underflow will show up and become
more and more severe. For a real burst transmission, time gap between two
message should be expected. Therefore, I feel confused about the using of
SOB and EOB tags here. Can they help to remove "underrun" under burst
transmission? If not, is there any other methods that can make burst
transmission with usrp possible without triggering underrun?

Thanks a lot for your help,
Yang
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Using Aurora enabled FPGA Image

[Nauman Iqbal via USRP-users]

Hi, I am trying to do the following,





1) Is it possible to use one of the HA/XA firmwares on the X310 in order to 
allow UHD configuration via the ethernet SFP+ port and streaming via the aurora 
SFP+ port directly to an FPGA which has aurora IP already working?

2) If so, then is the process straightforward on the driver end, i.e., 
requiring no modifications to the UHD? Is the UHD streaming procedure the same, 
provided that multi usrp objects are used?
3) Is there a suggested example that we could follow for such a case?

Regards

Nauman



From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of 
Nauman Iqbal via USRP-users
Sent: 01 August 2017 11:09
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Using Aurora enabled FPGA Image

Hi,
  I am trying to make an architecture in which I need to use one streaming 
channel with 10g Ethernet and the other channel over Aurora. I want to know if 
I can pass the configuration of both channels from one 10Gig link and is there  
a modification/tweaks needs to be done on UHD to support Aurora?

Regards

Nauman
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] PPS sync with USRP E310 timeout error

[Cho, Daniel J (332C) via USRP-users]

Hello Derek,

I thought the “set_time_unknown_pps” checks to confirm that the time is 
correctly set?
If that doesn’t, how do I know that the sync is set correctly without using a 
spectrum analyzer?

Thanks

From: Derek Kozel [mailto:derek.ko...@ettus.com]
Sent: Wednesday, August 2, 2017 7:33 AM
To: Cho, Daniel J (332C) 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] PPS sync with USRP E310 timeout error

Hello Daniel,
There is no check in your code to confirm that the time is correctly set. The 
1PPS signal should be a square wave rather than a sine wave. It is a logic 
signal rather than an RF one and the sync port is designed to handle it.
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_pps
The Octoclock which we use produces a 20% duty cycle square wave with 5V high 
and 0V low.

Regards,
Derek

On Wed, Aug 2, 2017 at 2:10 AM, Cho, Daniel J (332C) via USRP-users 
> wrote:
Hello –

I am using 2 USRP E310 which I would like to frequency sync together.  I am 
using a frequency generator which is generating a 1 PPS (1Hz sine wave) signal 
which I put through a power splitter to provide both USRPs with the same 1 PPS 
signal.  I configured the rx_samples_to_file and tx_samples_from_file codes to 
allow me to use the external 1PPS signal by including the following into the 
code:


//sleep off if gpsdo detected and time next pps already set


boost::this_thread::sleep(boost::posix_time::seconds(1));



//set time source if specified


if (not time_source.empty()) usrp->set_time_source(time_source);



//set the time at an unknown pps (will throw if no pps)


std::cout << std::endl << "Attempt to detect the PPS and set the time..." << 
std::endl << std::endl;


usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));


std::cout << std::endl << "Success!" << std::endl << std::endl;


When I run the rx_samples_to_file code with the above code included, I get a 
timeout error.  I found that it was due to the line 
“usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));”
How can I get my two USRPs frequency synced without getting this error?

Also, I saw that the 1 PPS signal provided to the USRP should be 3.3V – 5V.  
When I put a 1 PPS signal that strong on the spectrum analyzer, it shows a 
power output above +10 dBm.  I know that the max RX input power is -15 dBm so I 
was hesitant to input a 1 PPS signal that strong.  The 1 PPS signal I put into 
the sync port was 100 mV.  Even with a 1 PPS signal with an output power of 
100mV, I am still able to run the test_pps_input program successfully.

So in summary, should I just send a 1 PPS signal with a power output above +10 
dBm which equates to the 3.3V – 5V to the sync port even though I am able to 
run the test_pps_input program successfully with 100mV?  How can I get the 
rx_samples_to_file program to run successfully without giving me a timeout 
error using the above lines of code?

Thanks

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Trying to verify Rx MIMO operation of x310

[Derek Kozel via USRP-users]

Hi Mark,

I've added back on the list, it's useful to keep everyone in sync with
progress.

The WX FFT only takes one input but the QT Frequency Sync has a
configurable number of inputs. In general the QT GUIs are being promoted
over WX.

Regards,

Derek

On Tue, Aug 1, 2017 at 7:40 PM, Mark Koenig <
mark.koe...@iubelttechnologies.com> wrote:

> Thank you for the reply Derek.
>
>
>
> I set up a flow diagram in GNU radio companion with the USRP Source having
> 2 outputs and I want to route that to a WX GUI FFT sink, which accepts only
> one input.  Do I add an “add” block between the USRP source and GUI FFT
> Sink or a different block?
>
>
>
> Thanks
>
>
>
> Mark
>
>
>
> *From: *Derek Kozel 
> *Date: *Tuesday, August 1, 2017 at 11:11 AM
>
> *To: *Mark Koenig 
> *Cc: *"usrp-users@lists.ettus.com" 
> *Subject: *Re: [USRP-users] Trying to verify Rx MIMO operation of x310
>
>
>
> Hi Mark,
>
> Unfortunately you're up against the limits of the included examples. There
> are no UHD only examples which store multiple channels of samples to a
> file. The rx_multi_samples shows the steps involved in setting up the
> channels, but doesn't implement the functionality shown in
> rx_samples_to_file to write to a file.
>
> Yes, uhd_fft can be used to view multiple channels. GNU Radio's framework
> makes it easy to implement the more advanced application layer features.
> The arguments will be almost the same as for rx_multi_samples to file.
> Check out the help message for uhd_fft to see all the options. Simply
> supplying the frequency of interest and the same --channels 0,1 should show
> you plots of both channel's spectrum and time series data.
>
> To save data from both channels you will need to construct a flowgraph in
> GNU Radio. There are some examples supplied with gr-uhd which demonstrate
> the basics of connecting and configuring the USRP source. If you have
> trouble let us know here or on the GNU Radio mailing list.
>
> Regards,
>
> Derek
>
>
>
> On Tue, Aug 1, 2017 at 3:14 PM, Mark Koenig  iubelttechnologies.com> wrote:
>
> Thanks Derek.
>
>
>
> I was setting up rx_multi_samples the following way:
>
>
>
> ./rx_samples –args=”addr=192.168.40.2” –nsamps=1000 –rate=100e6
> –sync=now –subdev=”A:0 B:0” –channels=”0,1”
>
>
>
> I see a lot of verbose output, like:
>
>
>
> Received Packet:  1996 samples, 1 full secs, 0.50 frac secs
>
>
>
> But, I don’t get any file outputs or anything else.  The collection ends
> and I am left wondering what just happened.  Can I use uhd_fft to look at
> the MIMO stream?
>
>
>
> Also, there is no place to enter a frequency to collect, should there be?
>
>
>
> Mark
>
>
>
> *From: *Derek Kozel 
> *Date: *Tuesday, August 1, 2017 at 10:08 AM
> *To: *Mark Koenig 
> *Cc: *"usrp-users@lists.ettus.com" 
> *Subject: *Re: [USRP-users] Trying to verify Rx MIMO operation of x310
>
>
>
> Hello Mark,
>
> rx_samples_to_file will only receive a single channel. It is a minimal
> example.
>
> Try:
>
> rx_multi_samples --channels 0,1
>
> This will receive two channels, a pair of UBXs only has one RX channel per
> daughterboard so UHD can infer the sub device specification. The default
> sample rate is 100 MS/s so both channels will fit into a single 10 GigE
> connection. Make sure to follow the advice of any warnings printed to
> improve the throughput of your network interface card.
>
> If you have an external 1PPS source you can add `--sync pps --secs 0.1` to
> the above parameters to synchronize the two channels. The example currently
> forces an external source when synchronizing. If you remove/comment out
> line 98 and recompile it will use the internal source.
>
> Regards,
>
> Derek
>
>
>
>
>
> On Tue, Aug 1, 2017 at 2:46 PM, Mark Koenig via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I currently have an x310 with a ubx-40 in each of slots A and B.  I have
> one 10Gig Ethernet connection hooked up, and would like to receive on both
> channels A and B.
>
>
>
> I tried using the “rx_multi_samples” function, but I didn’t get a good
> feeling I was collecting on both channels.  I tried using the
> “rx_samples_to_file” function, but didn’t see a coherent collection on A
> and B, when setting the subdev to “A:0 B:0”.
>
> Finally, I tried the “uhd_fft”, and saw collection in channel A, but
> nothing from channel B, while setting subdev=”A:0 B:0”.
>
>
>
> Am I doing something incorrectly, or is there another function I should
> try?
>
>
>
> Thanks
>
>
>
> Mark
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com

Re: [USRP-users] PPS sync with USRP E310 timeout error

[Derek Kozel via USRP-users]

Hello Daniel,

There is no check in your code to confirm that the time is correctly set.
The 1PPS signal should be a square wave rather than a sine wave. It is a
logic signal rather than an RF one and the sync port is designed to handle
it.
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_pps

The Octoclock which we use produces a 20% duty cycle square wave with 5V
high and 0V low.

Regards,
Derek

On Wed, Aug 2, 2017 at 2:10 AM, Cho, Daniel J (332C) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello –
>
>
>
> I am using 2 USRP E310 which I would like to frequency sync together.  I
> am using a frequency generator which is generating a 1 PPS (1Hz sine wave)
> signal which I put through a power splitter to provide both USRPs with the
> same 1 PPS signal.  I configured the rx_samples_to_file and
> tx_samples_from_file codes to allow me to use the external 1PPS signal by
> including the following into the code:
>
>
>
> //sleep off if gpsdo detected and time next pps already set
>
> boost::this_thread::sleep(boost::posix_time::seconds(1));
>
> //set time source if specified
>
> if (not time_source.empty()) usrp->set_time_source(time_source);
>
> //set the time at an unknown pps (will throw if no pps)
>
> std::cout << std::endl << "Attempt to detect the PPS and set the time..."
> << std::endl << std::endl;
>
> usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
>
> std::cout << std::endl << "Success!" << std::endl << std::endl;
>
>
>
> When I run the rx_samples_to_file code with the above code included, I get
> a timeout error.  I found that it was due to the line “usrp->
> set_time_unknown_pps(uhd::time_spec_t(0.0));”
>
> How can I get my two USRPs frequency synced without getting this error?
>
>
>
> Also, I saw that the 1 PPS signal provided to the USRP should be 3.3V –
> 5V.  When I put a 1 PPS signal that strong on the spectrum analyzer, it
> shows a power output above +10 dBm.  I know that the max RX input power is
> -15 dBm so I was hesitant to input a 1 PPS signal that strong.  The 1 PPS
> signal I put into the sync port was 100 mV.  Even with a 1 PPS signal with
> an output power of 100mV, I am still able to run the test_pps_input program
> successfully.
>
>
>
> So in summary, should I just send a 1 PPS signal with a power output above
> +10 dBm which equates to the 3.3V – 5V to the sync port even though I am
> able to run the test_pps_input program successfully with 100mV?  How can I
> get the rx_samples_to_file program to run successfully without giving me a
> timeout error using the above lines of code?
>
>
>
> Thanks
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] FPGA Build problem

[EJ Kreinar via USRP-users]

Hi Nauman,

I'm guessing you're building FPGA for the X300 series.. Typically this is a
problem with setting the environment correctly.

In the build directory (uhd-fpga/usrp3/top/x300), first run "source
setupenv.sh". This calls uhd-fpga/usrp3/tools/scripts/setupenv_base.sh,
which populates the FPGA part types in your environment.

Hope this helps,
EJ

On Wed, Aug 2, 2017 at 6:45 AM, Nauman Iqbal via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>I am getting this error while I am trying to build the project from
> makefile. I have vivado paths already set.
>
>
>
> source /home/workspace/fpga/usrp3/tools/scripts/viv_generate_ip.tcl
>
> # set xci_file $::env(XCI_FILE)   ;
>
> # set part_name$::env(PART_NAME)  ;
>
> # set gen_example_proj $::env(GEN_EXAMPLE);
>
> # set synth_ip $::env(SYNTH_IP)   ;
>
> # set ip_name [file rootname [file tail $xci_file]]   ;
>
> # file delete -force "$xci_file.out"
>
> # create_project -part $part_name -in_memory -ip
>
> WARNING: [#UNDEF] No parts matched ''
>
> ERROR: [Coretcl 2-106] Specified part could not be found.
>
>
>
> Regards
>
>
>
> Nauman
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] what do fc64 and sc16 stand for?

[Claudio Cicconetti via USRP-users]

I guess it is:

f = float
s = signed integer
c = complex

Claudio

On 08/02/2017 12:47 PM, Ali The GREAT! via USRP-users wrote:
> Hi all,
> I wonder what fc64, fc32, sc16 and sc8 stand for.
> I know that fc64 = complex and so on.
> I just want to know the abbreviations.
> Thanks
> 
> love
> ali
> 
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] FPGA Build problem

[Nauman Iqbal via USRP-users]

Hi,
   I am getting this error while I am trying to build the project from 
makefile. I have vivado paths already set.

source /home/workspace/fpga/usrp3/tools/scripts/viv_generate_ip.tcl
# set xci_file $::env(XCI_FILE)   ;
# set part_name$::env(PART_NAME)  ;
# set gen_example_proj $::env(GEN_EXAMPLE);
# set synth_ip $::env(SYNTH_IP)   ;
# set ip_name [file rootname [file tail $xci_file]]   ;
# file delete -force "$xci_file.out"
# create_project -part $part_name -in_memory -ip
WARNING: [#UNDEF] No parts matched ''
ERROR: [Coretcl 2-106] Specified part could not be found.

Regards

Nauman
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com