[USRP-users] UHD C++ Chirp Signal

[Yeo Jin Kuang Alvin (IA) via USRP-users]

Hi all,

Does anyone know how to create a chirp signal using UHD C++? Are there any code 
examples and which files do I need?

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

Re: [USRP-users] N310 Subdevice Specification

[Sarah Tran via USRP-users]

Hi Nate,


Thank you for clarifying! I actually guessed and tried that subdev spec too, 
and while it got rid of the 'L's the 'S''s are still there and none of the leds 
come on. I am running at 12.5MHz. I am running the ofdm_tx.grx flowgraph and I 
made sure to get rid of the throttle block and replace the OFDM tranmitter 
block with the UHD sink block.


Thanks,


Sarah



From: Nate Temple 
Sent: Monday, April 23, 2018 4:12 PM
To: Sarah Tran
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] N310 Subdevice Specification

Hi Sarah,

For four channels on the N310 and UHD 3.11.0.1, the subdev spec will be  "A:0 
B:0 C:0 D:0".

What sample rate are you running at ?

Regards,
Nate Temple



On Mon, Apr 23, 2018 at 6:50 PM, Sarah Tran via USRP-users 
> wrote:
Hi all,

I recently got the N310, and I got one of the example programs from gr-digital 
to run on it. However because I didn't specify a subdevice, it only uses one 
channel. I want to be able to TX on all 4 channels but I couldn't get the right 
subdevice specification syntax correct. I tried "A:0 B:0" just to get maybe two 
channels transmitting, but it just printed out a lot of 'S' and 'L's. I also 
tried the syntax for the E310 "A:A A:B" which didn't work either. I know this 
is just my error, but I can't find much documentation on the correct syntax to 
use! I am using UHD version 3.11 and GNU Radio 3.7.11.1. Any help is greatly 
appreciated!


-Sarah Leony


___
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] N310 Subdevice Specification

[Nate Temple via USRP-users]

Hi Sarah,

For four channels on the N310 and UHD 3.11.0.1, the subdev spec will be
"A:0 B:0 C:0 D:0".

What sample rate are you running at ?

Regards,
Nate Temple



On Mon, Apr 23, 2018 at 6:50 PM, Sarah Tran via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
>
> I recently got the N310, and I got one of the example programs from
> gr-digital to run on it. However because I didn’t specify a subdevice, it
> only uses one channel. I want to be able to TX on all 4 channels but I
> couldn’t get the right subdevice specification syntax correct. I tried “A:0
> B:0” just to get maybe two channels transmitting, but it just printed out a
> lot of ‘S’ and ‘L’s. I also tried the syntax for the E310 “A:A A:B” which
> didn’t work either. I know this is just my error, but I can’t find much
> documentation on the correct syntax to use! I am using UHD version 3.11 and
> GNU Radio 3.7.11.1. Any help is greatly appreciated!
>
>
>
>
>
> -Sarah Leony
>
>
>
> ___
> 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] N310 Subdevice Specification

[Sarah Tran via USRP-users]

Hi all,

I recently got the N310, and I got one of the example programs from gr-digital 
to run on it. However because I didn’t specify a subdevice, it only uses one 
channel. I want to be able to TX on all 4 channels but I couldn’t get the right 
subdevice specification syntax correct. I tried “A:0 B:0” just to get maybe two 
channels transmitting, but it just printed out a lot of ‘S’ and ‘L’s. I also 
tried the syntax for the E310 “A:A A:B” which didn’t work either. I know this 
is just my error, but I can’t find much documentation on the correct syntax to 
use! I am using UHD version 3.11 and GNU Radio 3.7.11.1. Any help is greatly 
appreciated!


-Sarah Leony

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

Re: [USRP-users] problem to work witth source file and RFnoC block and FIR block

[Martin Braun via USRP-users]

On 04/21/2018 11:45 PM, Allouche Ishai wrote:
> Hi Martin,
> 
> Thank for your quick respond.
> 
> The output is invalid. In order to verify, I connect the output to 2 blocks: 
> File Sink and QT Sink.
> The File Sink don’t change and stay blank, and the QT Sink show zero all the 
> time ,in the frequency domain and the time domain.
> 
> But I saw that when I changed the Window block with FIR block the problem was 
> solved.  
> 
> Do you have any idea why the phenomenon happen when I use the Window block?

Can you elaborate on how the output is invalid?
Maybe it's todo with the vector nature of that block.

-- Martin

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

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[Michael West via USRP-users]

Hi Louis/Andrew,

The root cause of the issue has been identified and a fix is in progress.
We should have the fix available on the head of the maint branch very
soon.  Thank you for bringing it to our attention!

Regards,
Michael

On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have an issue that may be related. Using LFTX and LFRX boards in an
> X310, anytime I use the RFNoC Radio block in Rx mode the run terminates
> with:
>
> terminate called after throwing an instance of 'std::out_of_range'
>   what():  map::at
>
> Following for updates.
>
> Andrew
>
>
> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello Louis:
>>
>> Thanks for the detailed feedback. We have reproduced this issue, and are
>> debugging it now. We will get back to you and post an update shortly.
>>
>> --​Neel Pandeya
>>
>>
>>
>>
>> On 12 April 2018 at 18:46, Louis Brown via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Could it be something to do with this commit for address offsets?
>>>
>>> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
>>> 064b0dc6fbcc04c2ded94b4a
>>>
>>> Lou
>>>
>>>
>>> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
>>>
>>>
>>> Did something change with respect to daughter board addressing in UHD
>>> 3.11?
>>> I have an X310 with LFTX and LFRX  in motherboard slot A.
>>> When I run benchmark_rate it core dumps as follows:
>>>
>>> /*
>>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
>>> "addr=192.168.40.2" --tx_rate=10E6
>>>
>>> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5);
>>> Boost_106400; UHD_3.11.0.1-0-unknown
>>> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
>>> [INFO] [X300] X300 initialization sequence...
>>> [INFO] [X300] Determining maximum frame size...
>>> [INFO] [X300] Maximum frame size: 8000 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 DMA FIFO] BIST passed (Throughput: 1299 MB/s)
>>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
>>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
>>> [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1 input
>>> ports
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1 input
>>> ports
>>> [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
>>> Using Device: Single USRP:
>>> Device: X-Series Device
>>> Mboard 0: X310
>>> RX Channel: 0
>>> RX DSP: 0
>>> RX Dboard: A
>>> RX Subdev: LFRX (AB)
>>> RX Channel: 1
>>> RX DSP: 0
>>> RX Dboard: B
>>> RX Subdev: Unknown (0x) - 0
>>> TX Channel: 0
>>> TX DSP: 0
>>> TX Dboard: A
>>> TX Subdev: LFTX (AB)
>>> TX Channel: 1
>>> TX DSP: 0
>>> TX Dboard: B
>>> TX Subdev: Unknown (0x) - 0
>>>
>>> [00:00:02.623786] Setting device timestamp to 0...
>>> terminate called after throwing an instance of 'std::out_of_range'
>>> what(): map::at
>>> Aborted (core dumped)
>>> */
>>>
>>>
>>> If I specify tx_channels "1" it runs, lighting up the slot B TX/RX LED,
>>> or course I have no boards installed there.
>>>
>>> /*
>>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
>>> "addr=192.168.40.2" --tx_rate=100E6 --tx_channels "1"
>>> */
>>>
>>> If I specify tx_channels "0" it core dumps with the same
>>> std::out_of_range
>>>
>>> Flow graphs that ran in UHD 3.10 with sub-device "A:AB" no longer run:
>>>
>>> /*
>>> [INFO] [CORES] Timer loopback test passed
>>> terminate called after throwing an instance of 'std::out_of_range'
>>> what(): map::at
>>> */
>>>
>>> If I try benchmark_rate with another X310 with the UBX card in slot A,
>>> things work fine.  So maybe it's specific to the use of LF cards with UHD
>>> 3.11.
>>>
>>> Thanks,
>>> Lou
>>>
>>>
>>>
>>>
>>> ___
>>> 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 mailing list
USRP-users@lists.ettus.com

[USRP-users] Minimize latency over PCIe on X310

[Eugene Grayver via USRP-users]

Hello,

I am developing a custom c++ application (no GR) that takes data from the RX 
and  (for now) just pushes it to TX.  I am trying to achieve minimal latency 
(<<100 us).  The docs for X310 state that PCIe latency can be < 10 us.  I am 
not seeing that at all, the lowest I can get 350 us.

The setup is:

  *   Reset time to 0
  *   Set RX start time to 1.
  *   Set TX start time to 1 + DELTA
  *   Thread 1: read from RX streamer into a ring buffer
  *   Thread 2: read from ring buffer into TX streamer

NOTE: the threads are locked to cores and the process is given real-time 
priority.

Start lowering DELTA until we see 'L' packets.  I was able to get lower latency 
(180 us) using the 10 GbE interface, which should definitely not be the case!  
It has the network card latency + PCIe latency.

Using UHD 3.11

Can I set the PCIe transfer block size (like the frame size for UDP)?

Any other suggestions?

Thanks.

___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

Re: [USRP-users] BRAM usage of the X300/X310 design

[Nives Novković via USRP-users]

Hi Martin,

I saw that utilization report but as I can see it is not divided by blocks,
it just says the complete usage of resources? I understand about not being
able to provide the support for a completely stripped design, that is not
my intention. I have also tried to build the project following the
instructions but I got the error about design not satisfying timing
constraints.

Kind regards,
Nives

2018-04-19 23:18 GMT+02:00 Martin Braun :

> On 04/19/2018 07:35 AM, Nives Novković via USRP-users wrote:
> > I can see by the official numbers that the default Ettus FPGA design on
> > X310 takes about 50% BRAM and on X300 about 90%. I would like to make my
> > own design for Ettus but use only ADC and Ethernet cores from the
> > default design. Does anybody know how much BRAM blocks would only those
> > 2 cores from the original design take up? Thank you in advance!
>
> Our current UHD images packages (which you get when you run
> uhd_images_downloader) include a utilization report. I'm assuming you
> mean you want to remove all RFNoC blocks except for the radio -- if you
> really want to remove *everything*, that would be an invasive change,
> for which we wouldn't be able to provide any support.
>
> -- M
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] UBX 160 power constraint problem

[Zhou Liang via USRP-users]

Hi,


Previously I have posted the thread about the power issues of UBX 160 
daughterboard, I have been trying new driver 3.11 and different version of UBX 
160 and SBX v3. And I found that in TDD mode Tx power is different for 
different version of daughterboard.


It seems that for SBX V3 and UBX160 V1, maximum Tx power is quite strong while 
TX and RX sharing one anteena in TDD mode. However, if I swap to UBX160 V2 to 
run with same code and setting, it shows dramatically Tx power drop of about 
30dB weaker than with UBX160 V1.


According to manual of SPDT switch SKY13350-385LF, the isolation is about 22dB 
at 3.5GHz , which means that if we use maximum Tx and Rx gain we could burn 
mixer with power leaked through SPDT switch in TDD mode(20-22+31=29dbm>15dbm)? 
It seems that in V2 this is avoided by constraining Tx power to very low level 
in TDD mode. However, in our project we really need to have full Tx power in 
TDD mode, is there anyway to apply full transmit power on UBX160V2 in TDD mode?


Thank you very much!


Liang


Hi,


Thanks for the reply!


For the moment, if I upgrade to latest version of UHD, my programe does not 
work properly(lots of LL). Therefore I could not tell if it helps or not.

The "L" indicator indicates *late* samples--you are setting a send time on your 
bursts and by the time the burst arrives at the USRP, that
  time has already passed.  Make sure that you are properly synchronized in 
time with the USRP in scheduling bursts.

Yes, the TDD system is little complicated and it would be nice to figure out if 
new driver works before I adapt it to new driver. I will try to test new driver 
power output.




One burst is about half millisecond. I thought it is long enough, is it?

500usec should be long enough, yes.  There'll be a few usec of transition time 
at the beginning.

Do you have any clue about the reason for this very strange power issue? It 
seems that switch to port "RX2" change some setting and influence
the power output. Could you list some source file of uhd driver which might 
influence the power output?


Thank you very much!

Sincerely,

Liang Zhou




发件人: USRP-users 
 
代表 Marcus D. Leech via USRP-users 

发送时间: 2017年12月11日 8:13
收件人: usrp-users@lists.ettus.com
主题: Re: [USRP-users] Weak power with X310 and ubx160 with TDD system.

On 12/09/2017 08:27 AM, 周 亮 via USRP-users wrote:

Hi,


I build a TDD system with X310 and ubx160 v2, which uses TX/RX for both TX and 
RX. However I found the TX output power is extremely weak. Then I tried to 
assign RX2 as receiver anteena and I get approximately 20dB stronger TX signal 
with almost same code. The main difference is: for two anteena case, in each 
subframe TX send one burst, while in one anteena case, TX just sends zeros 
instead of stoping transmission. The installed uhd version is 3.9.7.


Does anybody know what could possibly be reason for this? And how could I 
achieve full power with single anteena TDD system?


Thank you!

Are you able to upgrade to a newer UHD version?  Does that help?

How long are your bursts?  Is it possible that they're shorter than the 
switching time?





___
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