[USRP-users] RFNoC Radio TX/RX vs USRP Sink/Source

[Dang tien Vo-Huu via USRP-users]

Hi all,
Recently I have some doubt about the difference between USRP Sink/Source
and the RFNoC Radio TX/RX. I found the answer in the knowledge base
https://kb.ettus.com/RFNoC but when I tried the RFNoC TX and RX flow
together, it didn't seem to be equivalent to the USRP Sink and Source
together: the RFNoC flow threw many "U" while the USRP Sink/Source flow ran
without any warning.

The USRP Sink/Source flow graph is very simple, it has 2 flows:
Noise Source --> USRP Sink
USRP Source --> Null Sink

The RFNoC flow graph:
Noise Source --> RFNoC DmaFIFO --> RFNoC DUC --> RFNoC Radio TX
RFNoC Radio RX --> RFNoC DDC --> Null Sink

And here is what I received when run RFNoC flow graph:
tienvh@gl502vm:~/workspace/rfnoc/src/rfnoc-tutorial/examples$ ./rfnoc_tx.py
-f 3000M -g 30 -s 20M
[INFO] [UHDlinux; GNU C++ version 5.4.1 20160904; Boost_105800;
UHD_4.0.0.rfnoc-devel-409-gec9138eb]
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Determining maximum frame size...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Setup basic communication...
[INFO] [X300] Loading values from EEPROM...
[INFO] [X300] Setup RF frontend clocking...
[INFO] [X300] Radio 1x clock:200
[INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
[INFO] [RFNOC] pass (Throughput: 1304.4MB/s)
[INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
[INFO] [RFNOC] pass (Throughput: 1299.7MB/s)
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
[INFO] [RFNOC] Assuming max packet size for 0/DUC_0
[INFO] [RFNOC] Assuming max packet size for 0/Radio_0
Press Enter to quit: UU






I did the comparison by building an image with 2 DDC and 2 DUC so that I
can run both RFNoC flow and legacy flow. I'm using USRP X310 with UBX and
the UHD version is UHD_4.0.0.rfnoc-devel-409-gec9138eb

Has anyone seen this before or has an intuition on this?
I also attach the flow graphs for more detail.

Thank you.

Best,
Tien


rfnoc_tx.grc
Description: application/gnuradio-grc


usrp_legacy.grc
Description: application/gnuradio-grc
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] OFDM TX/RX BER Calculator and ofdm_tx underruns with x310

[Sarah Tran via USRP-users]

Hi Michael,

I was able to make a PER block and it turns out I was dropping some packets, so 
when I took into account those dropped packets when I performed the BER, I was 
in a much better place 10e-2. Thank you for the explanation and help!

I had another question. I was previously using the N210 for this, and have 
since upgraded to the X310. However I get severe underruns (I tried the WBX and 
UBX-160 daughtercards). No matter what samp rate I use (from 400kHz to 10 MHz), 
I get lots of U’s printed on my console and then the X310 stops transmitting 
and freezes. I saw a previous thread that mentioned it was a problem with the 
UHD 3.10 code (which I am running), but didn’t say how it was fixed. (See 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/023924.html).
 Do you have any idea what the problem could be? I also put a null source 
instead of file source and changed the uhd sink to a probe+message debug, and 
it looks like my rates are good 2e7. The N210 works great and the X310 will 
transmit other data at the same rates, but not the ofdm_tx code.

Thank you!

Sarah

From: Michael Dickens 
Sent: Thursday, March 8, 2018 6:12 AM
To: Sarah Tran ; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] OFDM TX/RX BER Calculator

Hi Sarah - Glad you're heading down a positive path.

The header data is removed from the raw data being decoded, but added as 
meta-data on the stream. This meta-data is optionally printed out by GR OFDM 
and/or various Qt displays. Once the header has been verified (via CRC8), it is 
no longer part of the raw OFDM symbol data.

Cheers! - MLD

On Wed, Mar 7, 2018, at 9:11 PM, Sarah Tran wrote:

Thank you for your quick response! I wanted the payload to be QPSK modulated. I 
put a QT Range blocks in for the gain settings on the ofdm_tx and ofdm_rx 
flowgraphs. I still can’t seem to get any better than 20% BER though, but I 
think the advice about doing a PER calculator is pointing me in the right 
direction as a lost packet would definitely screw up the BER. So thank you very 
much for the advice!!



I did have another question though regarding the metadata that still has me 
confused. If the header data is taken out of the payload, why does it still 
show up when I put a time sink after the payload gettings decoded (after the 
constellation decoder/stream CR32 blocks)? It plots the decoded bits as well as 
the packet num, carrier_offset, etc. Did I put my time sink in the wrong place?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Spikes at beginning and end of transmission

[Michael West via USRP-users]

Hi Thomas,

This is a known hardware issue with earlier revisions of the B200mini and
has been fixed on newer versions.  Please contact supp...@ettus.com and
they can help get the boards reworked.

Regards,
Michael

On Sun, Feb 25, 2018 at 6:54 AM, Thomas Teisberg via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I'm sorry, which thread are you referring to?
>
> I have tried implementing the changes in the thread I originally linked to
> and it doesn't seem to have made any difference.
>
> Best,
> Thomas
>
> On Feb 25, 2018 4:52 AM, "Steven Knudsen"  wrote:
>
>> Hi,
>>
>> This is a known problem with the B20xmini. Have a look at this thread and
>> then follow it up.
>>
>> You are right, you are seeing caps charge and discharge, basically.
>>
>> Since I made the changes myself on my units, I am not sure where things
>> were left with Ettus and their policy for fixing the problem. But I can say
>> that once you make the changes, the transients are gone and the minis work
>> really well.
>>
>> regards,
>>
>> steven
>>
>>
>> On Sat, Feb 24, 2018 at 3:25 PM, Thomas Teisberg via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I'm working on a radar project that requires sending a series of short
>>> pulses. Looking at the pulses on a scope, I'm seeing large voltage spikes
>>> at the beginning and the end of each transmission.
>>>
>>> As shown in the attached screenshot, before the transmission starts,
>>> there is a 90 mV spike lasting about 10 us. After the transmission, there's
>>> a -25 mV spike lasting about 20 us.
>>>
>>> The setup for this is simply a USRP B205mini-i connected to a 50 ohm
>>> input on a scope through a 30 dB attenuator. The signal is at 435 MHz with
>>> the scope sampling at 20 Gsps.
>>>
>>> Our initial thought was that we must be seeing some effects of some of
>>> the RF frontend components turning on and off. I found this previous
>>> mailing list post and tried the suggested fix in b200_impl.cpp but nothing
>>> changed:
>>>
>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
>>> 2015-January/012269.html
>>>
>>> Any ideas why we might be seeing these spikes or what we could do about
>>> it? Does the fix suggested in the above mailing list post still apply to
>>> the current codebase?
>>>
>>> Thanks,
>>> Thomas
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>> --
>> K. Steven Knudsen, Ph.D., P.Eng.
>>
>
> ___
> 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 block timeouts

[Brian Padalino via USRP-users]

On Thu, Mar 15, 2018 at 2:20 PM, EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Sebastian,
>
> > Does RFNoC assume that a block always has to output samples within a
> certain time limit? Can someone explain to me, where the timeout is checked
> and raised?
>
> You can find the "timeout on chan 0" message implemented in
> gr-ettus/lib/rfnoc_block_impl.cc. As you suspected (correctly), it is a
> harmless output that can be ignored if no data is actually coming from your
> RFNoC block. It is driven by receiving a timeout from the streamer->recv()
> function -- it looks like the timeout defaults to 0.1 seconds.
>
>
Why is there a poke32 timeout when it's trying to receive something?  That
doesn't make any sense to me.

What is being poked to the block and, even though there is no AXI data
flowing, why would the block timeout?

I've seen this happen as well, for some of my custom blocks, and I would
like to know needs to happen from an RFNoC perspective to ensure things
stay alive.

The second message about a task loop exiting, from my experience, basically
causes the X310 to become unresponsive until an FPGA reload which is absurd
to me.

Is there a resource which explains exactly what "background" communication
is occurring that would cause this error?

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

Re: [USRP-users] RFNoC block timeouts

[EJ Kreinar via USRP-users]

Hi Sebastian,

> Does RFNoC assume that a block always has to output samples within a
certain time limit? Can someone explain to me, where the timeout is checked
and raised?

You can find the "timeout on chan 0" message implemented in
gr-ettus/lib/rfnoc_block_impl.cc. As you suspected (correctly), it is a
harmless output that can be ignored if no data is actually coming from your
RFNoC block. It is driven by receiving a timeout from the streamer->recv()
function -- it looks like the timeout defaults to 0.1 seconds.


I'm not familiar with the second error, however :) Sorry!

EJ


On Thu, Mar 15, 2018 at 1:55 PM, Sebastian Leutner via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I have a custom RFNoC block which detects data packets in a stream of
> I/Q-samples coming from a file source or the RFNoC Radio block. It only
> outputs samples if it detects a packet, otherwise it does not output
> anything. This works fine in simulation but when using the synthesized
> block, I get "timeout on chan 0" messages as soon as there is nothing
> detected and thus no output from my block. I suppose this principle is
> relevant for any radio receiver implementation in RFNoC. I am using the
> X310 with UHD 4.0.0.rfnoc-devel-409-gec9138eb.
>
> I have problems figuring out how this timeout is implemented exactly. Does
> RFNoC assume that a block always has to output samples within a certain
> time limit? Can someone explain to me, where the timeout is checked and
> raised? Is the ZPU responsible for this?
>
> Just ignoring the timeout messages works up to a certain point where I get
> the following error messages. Valid data samples are not processed any
> more after this happens.
>   [ERROR] [X300] x300 fw communication failure #1 EnvironmentError:
> IOError: x300 fw poke32 - reply timed out
>   [ERROR] [X300] x300 fw communication failure #2 EnvironmentError:
> IOError: x300 fw poke32 - reply timed out
>   [ERROR] [X300] x300 fw communication failure #3 EnvironmentError:
> IOError: x300 fw poke32 - reply timed out
>   [ERROR] [UHD] An unexpected exception was caught in a task loop.The
> task loop will now exit, things may not work. x300 fw communication failure
> #3 EnvironmentError: IOError: x300 fw poke32 - reply timed out
>
> Any help or ideas appreciated!
>
> Best regards,
> Sebastian
>
>
> ___
> 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 block timeouts

[Sebastian Leutner via USRP-users]

Hi all,

I have a custom RFNoC block which detects data packets in a stream of 
I/Q-samples coming from a file source or the RFNoC Radio block. It only 
outputs samples if it detects a packet, otherwise it does not output 
anything. This works fine in simulation but when using the synthesized 
block, I get "timeout on chan 0" messages as soon as there is nothing 
detected and thus no output from my block. I suppose this principle is 
relevant for any radio receiver implementation in RFNoC. I am using the 
X310 with UHD 4.0.0.rfnoc-devel-409-gec9138eb.


I have problems figuring out how this timeout is implemented exactly. Does 
RFNoC assume that a block always has to output samples within a certain 
time limit? Can someone explain to me, where the timeout is checked and 
raised? Is the ZPU responsible for this?


Just ignoring the timeout messages works up to a certain point where I get 
the following error messages. Valid data samples are not processed any more 
after this happens.
 [ERROR] [X300] x300 fw communication failure #1 EnvironmentError: 
IOError: x300 fw poke32 - reply timed out
 [ERROR] [X300] x300 fw communication failure #2 EnvironmentError: 
IOError: x300 fw poke32 - reply timed out
 [ERROR] [X300] x300 fw communication failure #3 EnvironmentError: 
IOError: x300 fw poke32 - reply timed out
 [ERROR] [UHD] An unexpected exception was caught in a task loop.The task 
loop will now exit, things may not work. x300 fw communication failure #3 
EnvironmentError: IOError: x300 fw poke32 - reply timed out


Any help or ideas appreciated!

Best regards,
Sebastian

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

[USRP-users] FWD: set_rx_lo_source repeat

[Андрей 1 via USRP-users]

I think that the results with clock() are correct.The main issue is that the 
time
at which data from all frequencies is present is meaningably greater than 5 
msюIf
I set the time to 5 ms as in the original example, the receiver will not be able
to rebuild and the time measurement shows that it needs 45 ms.

.
 Пересылаемое сообщение 
От: Андрей 1 
Дата: 15.03.2018, 16:54
Кому: Usrp Users 
Тема: set_rx_lo_source repeat
HelloEarlier I already wrote about big times for the example of
twinrx_freq_hopping
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-February/027782.htmlCan
anyone analyze the source code(rx_samples_c in the attachment) and say why it
turns out such a strange result (TestTwinRX) when called set_rx_lo_source.

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

Re: [USRP-users] set_rx_lo_source repeat

[Marcus D. Leech via USRP-users]

On 03/15/2018 10:54 AM, Андрей 1 via USRP-users wrote:

Hello
Earlier I already wrote about big times for the example of 
twinrx_freq_hopping 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-February/027782.html
Can anyone analyze the source code(rx_samples_c in the attachment) and 
say why it turns out such a strange result (TestTwinRX) when called 
set_rx_lo_source.



Thank you


I will observe that if you want to check for real-time, as opposed to 
CPU-occupancy-time,  using clock() is not the right tool.


I'd use gettimeofday() or similar.




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

[USRP-users] set_rx_lo_source repeat

[Андрей 1 via USRP-users]

HelloEarlier I already wrote about big times for the example of
twinrx_freq_hopping
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-February/027782.htmlCan
anyone analyze the source code(rx_samples_c in the attachment) and say why it
turns out such a strange result (TestTwinRX) when called set_rx_lo_source.

Thank you
/*
 * Copyright 2015 Ettus Research LLC
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see .
 */

#include 

#include "getopt.h"

#include 
#include 
#include 
#include 

#define EXECUTE_OR_GOTO(label, ...) \
if(__VA_ARGS__){ \
return_code = EXIT_FAILURE; \
goto label; \
}

#define MIN(x,y) (((x) < (y)) ? (x):(y))

void print_help(void){
fprintf(stderr, "rx_samples_c - A simple RX example using UHD's C API\n\n"

"Options:\n"
"-a (device args)\n"
"-f (frequency in Hz)\n"
"-r (sample rate in Hz)\n"
"-g (gain)\n"
"-n (number of samples to receive)\n"
"-o (output filename, default = \"out.dat\")\n"
"-v (enable verbose prints)\n"
"-h (print this help message)\n");
};

#define spb 1024
#define fcount 11

size_t ACTIVE_CHAN = 0;
size_t UNUSED_CHAN = 1;

uhd_usrp_handle usrp;
uhd_rx_streamer_handle streamer;
uhd_rx_metadata_handle metadata;

double f1 = 100e+6;
double f2 = 110e+6;
double fs = 1e+6;

double receive_interval = 50e-3;

size_t recv_spb;

double rf_freqs[fcount];
float data[fcount*spb*2]; // 100..110 freq range

uhd_error set_device_subspec(uhd_usrp_handle h,
   const char* markup)
{
uhd_error e;
uhd_subdev_spec_handle spec;

e = uhd_subdev_spec_make(&spec,markup);
if (e == UHD_ERROR_NONE)
e = uhd_usrp_set_rx_subdev_spec(h,spec,0);
uhd_subdev_spec_free(&spec);

return e;
}

uhd_error init_device_stream(uhd_usrp_handle h,
 uhd_rx_streamer_handle sh)
{
uhd_stream_args_t stream_args = {
.cpu_format = "fc32",
.otw_format = "sc16",
.args = "",
.channel_list = &ACTIVE_CHAN,
.n_channels = 1
};

return uhd_usrp_get_rx_stream(h,&stream_args,sh);
}

uhd_error set_device_freq(uhd_usrp_handle h,
  double freq,
  size_t chan)
{
uhd_tune_request_t tune_request = {
.target_freq = freq,
.rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
.dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
};
uhd_tune_result_t tune_result;

return uhd_usrp_set_rx_freq(h,&tune_request,chan,&tune_result);
}

uhd_error init_commands(uhd_usrp_handle h,
uhd_rx_streamer_handle sh,
int n)
{
uhd_error e;

e = uhd_usrp_set_time_now(h,0,0,0);
if (e != UHD_ERROR_NONE) return e;

uhd_stream_cmd_t stream_cmd = {
.stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE,
.num_samps = spb,
.stream_now = false
};

double command_time = 0;

for(int i=0; i___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Configurating B210 transmitter into two different central frequencies.

[Kyeong Su Shin via USRP-users]

(You can ignore my previous response, if you read Derek's response - poor 
timing.)


An alternative way to fix the problem (when you need to xmit on two different 
frequencies which are not located close enough) is to use the B210 as IF stages 
and to add your own RF stages on top of it. Anyway, this is a hardware 
limitation and the only way to fix the problem is to add more hardware (or 
re-design the system, so as you wouldn't have to transmit on two distinct 
frequencies).


Regards,

Kyeong Su Shin


보낸 사람: Kyeong Su Shin via USRP-users  대신 USRP-users 

보낸 날짜: 2018년 3월 15일 목요일 오후 10:39:12
받는 사람: Jose Benito Diéguez Teixeira; usrp-users@lists.ettus.com
제목: Re: [USRP-users] Configurating B210 transmitter into two different central 
frequencies.


Hello José,


I am pretty sure that AD9361 has only one PLL for the both TX chains. So, there 
is a hardware-level limitation for this.


If the difference between the highest (RF) frequency and the lowest (RF) 
frequency occupied by the two waveforms (combined) is smaller than the 
effective sampling rate of the board, you will be able to transmit the two 
different signals. If the seperation has to be larger, you are pretty much out 
of luck. The easiest fix is to get more USRPs and synchronize them (if 
necessary) using a reference signal.


Regards,

Kyeong Su Shin



보낸 사람: Jose Benito Diéguez Teixeira via USRP-users  
대신 USRP-users 
보낸 날짜: 2018년 3월 15일 목요일 오후 10:22:52
받는 사람: usrp-users@lists.ettus.com
제목: [USRP-users] Configurating B210 transmitter into two different central 
frequencies.

Hello usrp users,

We are using a B210 SDR device for our application. This device has two RF 
frontends, but we are in doubt about their mutual independence. We need to 
transmit two different waveforms, each into its own frequency.

We have tried to create two tx_streamers, but the creation of the second one 
seems to overwrite the first streamer. Is this approach the correct way to 
implement the dual frequency transmittion?

Or more focused on the hardaware, is it possible to set two different 
transmittion frequencies with the B210?

Thanks in advance,


--






José Benito Diéguez Teixeira
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] set_rx_lo_source

[Андрей 1 via USRP-users]

Source code in the attachment

 15.03.2018, 15:44, Андрей 1 Hello
 I duplicated the attachment with the source code.Derek can you see what's
 wrong.I can understand what the maximum speed of perestroika I can get with
 TwinRX.

 Thank you
/*
 * Copyright 2015 Ettus Research LLC
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see .
 */

#include 

#include "getopt.h"

#include 
#include 
#include 
#include 

#define EXECUTE_OR_GOTO(label, ...) \
if(__VA_ARGS__){ \
return_code = EXIT_FAILURE; \
goto label; \
}

#define MIN(x,y) (((x) < (y)) ? (x):(y))

void print_help(void){
fprintf(stderr, "rx_samples_c - A simple RX example using UHD's C API\n\n"

"Options:\n"
"-a (device args)\n"
"-f (frequency in Hz)\n"
"-r (sample rate in Hz)\n"
"-g (gain)\n"
"-n (number of samples to receive)\n"
"-o (output filename, default = \"out.dat\")\n"
"-v (enable verbose prints)\n"
"-h (print this help message)\n");
};

#define spb 1024
#define fcount 11

size_t ACTIVE_CHAN = 0;
size_t UNUSED_CHAN = 1;

uhd_usrp_handle usrp;
uhd_rx_streamer_handle streamer;
uhd_rx_metadata_handle metadata;

double f1 = 100e+6;
double f2 = 110e+6;
double fs = 1e+6;

double receive_interval = 50e-3;

size_t recv_spb;

double rf_freqs[fcount];
float data[fcount*spb*2]; // 100..110 freq range

uhd_error set_device_subspec(uhd_usrp_handle h,
   const char* markup)
{
uhd_error e;
uhd_subdev_spec_handle spec;

e = uhd_subdev_spec_make(&spec,markup);
if (e == UHD_ERROR_NONE)
e = uhd_usrp_set_rx_subdev_spec(h,spec,0);
uhd_subdev_spec_free(&spec);

return e;
}

uhd_error init_device_stream(uhd_usrp_handle h,
 uhd_rx_streamer_handle sh)
{
uhd_stream_args_t stream_args = {
.cpu_format = "fc32",
.otw_format = "sc16",
.args = "",
.channel_list = &ACTIVE_CHAN,
.n_channels = 1
};

return uhd_usrp_get_rx_stream(h,&stream_args,sh);
}

uhd_error set_device_freq(uhd_usrp_handle h,
  double freq,
  size_t chan)
{
uhd_tune_request_t tune_request = {
.target_freq = freq,
.rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
.dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
};
uhd_tune_result_t tune_result;

return uhd_usrp_set_rx_freq(h,&tune_request,chan,&tune_result);
}

uhd_error init_commands(uhd_usrp_handle h,
uhd_rx_streamer_handle sh,
int n)
{
uhd_error e;

e = uhd_usrp_set_time_now(h,0,0,0);
if (e != UHD_ERROR_NONE) return e;

uhd_stream_cmd_t stream_cmd = {
.stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE,
.num_samps = spb,
.stream_now = false
};

double command_time = 0;

for(int i=0; i___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] set_rx_lo_source

[Андрей 1 via USRP-users]

Hello
I duplicated the attachment with the source code.Derek can you see what's 
wrong.I
can understand what the maximum speed of perestroika I can get with TwinRX.
Thank you
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210 issues with sample rate and Tx bandwidth

[Derek Kozel via USRP-users]

Hello Lucas,

I'll address your last question. The limitation is a hardware one as the
FPGA is connected to the AD9361 using the CMOS interface and the bandwidth
is split between the channels. This cannot be changed on the B210.

Regards,
Derek

On Thu, Mar 15, 2018 at 11:57 AM, Lucas Val Terrón via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Over the uhd example tx_waveforms.cpp (without any modificaiton), the
> exact invocation I'm using is the following:
>
> ./tx_waveforms --rate 6144 --bw 5000 --freq 244000 --channels
> "0" --wave-type SINE --wave-freq 10 --gain 60
>
> and its output:
>
> --
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.11.0.git-208-g1da86f9c]
> [INFO] [B200] Detected Device: B210
> [INFO] [B200] Operating over USB 3.
> [INFO] [B200] Initialize CODEC control...
> [INFO] [B200] Initialize Radio control...
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] pass
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] pass
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [AD936X] Performing CODEC loopback test...
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [B200] Setting master clock rate selection to 'automatic'.
> [INFO] [B200] Asking for clock rate 16.00 MHz...
> [INFO] [B200] Actually got clock rate 16.00 MHz.
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> Using Device: Single USRP:
>   Device: B-Series Device
>   Mboard 0: B210
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
>   RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: FE-RX1
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
>   TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
>
> Setting TX Rate: 61.44 Msps...
> [INFO] [B200] Asking for clock rate 61.44 MHz...
> [INFO] [B200] Actually got clock rate 61.44 MHz.
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> Actual TX Rate: 61.44 Msps...
>
> Setting TX Freq: 2440.00 MHz...
> Actual TX Freq: 2440.00 MHz...
>
> Setting TX Gain: 60.00 dB...
> Actual TX Gain: 60.00 dB...
>
>
> *Setting TX Bandwidth: 5000.00 MHz...Actual TX Bandwidth:
> 4000.00 MHz...*
>
>
> *[WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceedsanalog
> frontend filter bandwidth (56 MHz).*
> Setting device timestamp to 0...
> Checking TX: LO: locked ...
> Press Ctrl + C to stop streaming...
> --
>
> The invocation does not produce any error, but there is a warning that
> makes believe that somewhere inside the code something is trying to set th
> BW to the same value as the sample rate. Furthermore, you can also see that
> although the BW inserted is 50MHz, the value is finally set to 40MHz...
>
>
> If you don't mind, let me take the opportunity to ask you about a doubt
> related to the sample rate and dual channel transmission. Looking in the
> documentation I found here (https://files.ettus.com/manua
> l/page_usrp_b200.html#b200_mcr), that there is a limitation of 30.72 MHz
> in the clock rate for dual-channel mode. What is this limitation related
> to? Host, UHD, FPGA, AD9361 chip? Is there any way to increase this value?
>
> [image: logo_170x100px.png] 
>
>
>
> Lucas Val Terrón
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
>
> Researcher - Developer | Advanced Communications Department
>
>
>
> Ph. (+34) 986 120 430 <+34%20986%2012%2004%2030>  Ext. 3016
> l...@gradiant.org  |  www.gradiant.org
>
> [image: Iconos Redes Sociales GRD Firma email-01]
>   [image: Iconos Redes Sociales
> GRD Firma email-02]   [image: Iconos Redes
> Sociales GRD Firma email-03]
>   [image: Iconos Redes
> Sociales GRD Firma email-04]
> 
>
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
>
> 2018-03-14 10:36 GMT+01:00 Lucas Val Terrón :
>
>> Hi all,
>>
>> Working with the example "tx_waveforms.cpp" provided in the uhd, i found
>> myself with two problems trying to set the sample rate and the tx bandwith
>> of the USRP B210 (UHD_3.11.0).
>>
>> ./tx_waveforms --rate 61

Re: [USRP-users] Configurating B210 transmitter into two different central frequencies.

[Kyeong Su Shin via USRP-users]

Hello José,


I am pretty sure that AD9361 has only one PLL for the both TX chains. So, there 
is a hardware-level limitation for this.


If the difference between the highest (RF) frequency and the lowest (RF) 
frequency occupied by the two waveforms (combined) is smaller than the 
effective sampling rate of the board, you will be able to transmit the two 
different signals. If the seperation has to be larger, you are pretty much out 
of luck. The easiest fix is to get more USRPs and synchronize them (if 
necessary) using a reference signal.


Regards,

Kyeong Su Shin



보낸 사람: Jose Benito Diéguez Teixeira via USRP-users  
대신 USRP-users 
보낸 날짜: 2018년 3월 15일 목요일 오후 10:22:52
받는 사람: usrp-users@lists.ettus.com
제목: [USRP-users] Configurating B210 transmitter into two different central 
frequencies.

Hello usrp users,

We are using a B210 SDR device for our application. This device has two RF 
frontends, but we are in doubt about their mutual independence. We need to 
transmit two different waveforms, each into its own frequency.

We have tried to create two tx_streamers, but the creation of the second one 
seems to overwrite the first streamer. Is this approach the correct way to 
implement the dual frequency transmittion?

Or more focused on the hardaware, is it possible to set two different 
transmittion frequencies with the B210?

Thanks in advance,


--






José Benito Diéguez Teixeira
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Configurating B210 transmitter into two different central frequencies.

[Derek Kozel via USRP-users]

Hello Jose,

The B210's two channels use a common local oscillator so cannot tune to two
separate analog frequencies.
http://files.ettus.com/manual/page_usrp_b200.html#b200_fe

However if your two center frequencies are relatively close together, such
that the minimum and maximum frequencies of your modulated waveforms are
less than 30.72 MHz apart the FPGA's frequency shifters can be used to
digitally tune each channel's center frequency. The basics of this are
described on this page in the manual. We'd be happy to describe the process
in more detail if it fits your application.
http://files.ettus.com/manual/page_general.html#general_tuning_process

Regards,
Derek


On Thu, Mar 15, 2018 at 1:22 PM, Jose Benito Diéguez Teixeira via
USRP-users  wrote:

> Hello usrp users,
>
> We are using a B210 SDR device for our application. This device has two RF
> frontends, but we are in doubt about their mutual independence. We need to
> transmit two different waveforms, each into its own frequency.
>
> We have tried to create two tx_streamers, but the creation of the second
> one seems to overwrite the first streamer. Is this approach the correct way
> to implement the dual frequency transmittion?
>
> Or more focused on the hardaware, is it possible to set two different
> transmittion frequencies with the B210?
>
> Thanks in advance,
>
>
> --
>
>
> 
>
>
>
> José Benito Diéguez Teixeira
>
> ___
> 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] Configurating B210 transmitter into two different central frequencies.

[Jose Benito Diéguez Teixeira via USRP-users]

Hello usrp users,

We are using a B210 SDR device for our application. This device has two RF
frontends, but we are in doubt about their mutual independence. We need to
transmit two different waveforms, each into its own frequency.

We have tried to create two tx_streamers, but the creation of the second
one seems to overwrite the first streamer. Is this approach the correct way
to implement the dual frequency transmittion?

Or more focused on the hardaware, is it possible to set two different
transmittion frequencies with the B210?

Thanks in advance,


-- 






José Benito Diéguez Teixeira
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210 issues with sample rate and Tx bandwidth

[Lucas Val Terrón via USRP-users]

Over the uhd example tx_waveforms.cpp (without any modificaiton), the exact
invocation I'm using is the following:

./tx_waveforms --rate 6144 --bw 5000 --freq 244000 --channels
"0" --wave-type SINE --wave-freq 10 --gain 60

and its output:

--
[INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.11.0.git-208-g1da86f9c]
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] pass
[INFO] [B200] Performing register loopback test...
[INFO] [B200] pass
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 MHz.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
Using Device: Single USRP:
  Device: B-Series Device
  Mboard 0: B210
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX2
  RX Channel: 1
RX DSP: 1
RX Dboard: A
RX Subdev: FE-RX1
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX2
  TX Channel: 1
TX DSP: 1
TX Dboard: A
TX Subdev: FE-TX1

Setting TX Rate: 61.44 Msps...
[INFO] [B200] Asking for clock rate 61.44 MHz...
[INFO] [B200] Actually got clock rate 61.44 MHz.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
Actual TX Rate: 61.44 Msps...

Setting TX Freq: 2440.00 MHz...
Actual TX Freq: 2440.00 MHz...

Setting TX Gain: 60.00 dB...
Actual TX Gain: 60.00 dB...


*Setting TX Bandwidth: 5000.00 MHz...Actual TX Bandwidth:
4000.00 MHz...*


*[WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceedsanalog
frontend filter bandwidth (56 MHz).*
Setting device timestamp to 0...
Checking TX: LO: locked ...
Press Ctrl + C to stop streaming...
--

The invocation does not produce any error, but there is a warning that
makes believe that somewhere inside the code something is trying to set th
BW to the same value as the sample rate. Furthermore, you can also see that
although the BW inserted is 50MHz, the value is finally set to 40MHz...


If you don't mind, let me take the opportunity to ask you about a doubt
related to the sample rate and dual channel transmission. Looking in the
documentation I found here (https://files.ettus.com/manua
l/page_usrp_b200.html#b200_mcr), that there is a limitation of 30.72 MHz in
the clock rate for dual-channel mode. What is this limitation related to?
Host, UHD, FPGA, AD9361 chip? Is there any way to increase this value?

[image: logo_170x100px.png] 



Lucas Val Terrón
Investigador - Desarrollador | Área de Comunicaciones Avanzadas

Researcher - Developer | Advanced Communications Department



Ph. (+34) 986 120 430  Ext. 3016
l...@gradiant.org  |  www.gradiant.org

[image: Iconos Redes Sociales GRD Firma email-01]
  [image: Iconos Redes Sociales GRD
Firma email-02]   [image: Iconos Redes
Sociales GRD Firma email-03] 
 [image: Iconos Redes Sociales GRD Firma email-04]


Take care of the environment. Try not to print this email.
The information contained in this email message may be confidential
information, and may also be the subject of legal professional privilege.
If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorized and prohibited.
Please inform us immediately and destroy the email. Thank you for your
cooperation.

2018-03-14 10:36 GMT+01:00 Lucas Val Terrón :

> Hi all,
>
> Working with the example "tx_waveforms.cpp" provided in the uhd, i found
> myself with two problems trying to set the sample rate and the tx bandwith
> of the USRP B210 (UHD_3.11.0).
>
> ./tx_waveforms --rate 6144 --freq 235000 --wave-type SINE
> --wave-freq 100 --gain 40 --bw 5000 (with sc16 format)
>
>
> 1. The first thing I realized is that despite the sample rate was the
> maximum available, the bandwidth is limited to 40 MHz. Furthermore, the
> following warning appears:
>
> [WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceeds
>
> So, it seems that somewhere inside the code tries to set the Tx bandwith
> to the same value as the sample rate...
>
>
> ./tx_waveforms --rate 5 --freq 235000 --wave-type SINE
> --wave-freq 100 --gain 40 --bw 5000 (with sc16 for

Re: [USRP-users] Align LOs in the front-end for Tx

[Derek Kozel via USRP-users]

Hello,

Yes, the same use of timed commands applies for the transmit side tuning.
Just use set_tx_freq instead of set_rx_freq. The timed command
functionality applies to many features on the X310 such as setting the
gain, selecting antennas, and other commands.

Regards,
Derek

On Thu, Mar 15, 2018 at 10:30 AM, Hojoon Yang via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all.
>
>
>
> Let's say we have one USRP X310 and two UBX-160 daughterboards.
>
>
>
> According to the page_sync manual(i.e. https://files.
> ettus.com/manual/page_sync.html), there is a code snippet for aligning
> LOs.
>
>
> Do I need to execute the same thing for Tx? Because the code only
> describes for Rx case.
>
>
>
> Regards,
>
> ___
> 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] Align LOs in the front-end for Tx

[Hojoon Yang via USRP-users]

Hi all.Let's say we have one USRP X310 and two UBX-160 daughterboards.According 
to the page_sync manual(i.e. https://files.ettus.com/manual/page_sync.html), 
there is a code snippet for aligning LOs.Do I need to execute the same thing 
for Tx? Because the code only describes for Rx case.Regards,___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com