[USRP-users] pause streaming

[Koyel Das (Vehere) via USRP-users]

Hi,


Is there a way to pause streaming data from USRP 2955R and resume back? What is 
the code/ command for that? Is there an example available?

Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] changing frequency on the fly

[Koyel Das (Vehere) via USRP-users]

Hi,


I am streaming data from USRP 2955R from 4 channels. Basic code is 
rx_multisamples.cpp .


1.I want to scan frequencies that is change centre frequency on the fly. So do 
I have to discard some packets after changing frequencies so that data from one 
frequency doesn't enter another frequency data buffer? If so how many data 
samples? Or what precautions have to be taken  to avoid data from one frequency 
entering another frequency data buffer?


2.Is there some other precaution I need to take for implementing scanning or 
changing frequencies?


Regards,

Koyel Das

Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] not getting phase coherence between channels

[Koyel Das (Vehere) via USRP-users]

Hi Marcus,


Thanks its clear now.

Regards,


Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.


From: Marcus D. Leech 
Sent: Wednesday, April 3, 2019 8:00:45 PM
To: Koyel Das (Vehere); 'USRP-users@lists.ettus.com'
Subject: Re: [USRP-users] not getting phase coherence between channels

On 04/03/2019 05:55 AM, Koyel Das (Vehere) wrote:

Hi Marcus,


Thank you very much for your reply. I have few doubts. Please clarify:


In the link that you sent there are total 8 sma ports for A slot and B slot

LO Sharing with Neighbour TwinRXs
TwinRX (A Slot) TwinRX (B Slot)
J1 LO2 Export   J2 LO2 Input
J2 LO2 InputJ1 LO2 Export
J3 LO1 Export   J4 LO1 Input
J4 LO1 InputJ3 LO1 Export


But in USRP 2955R only 4 ports are exposed out, so the configuration what is 
given in your link is totally different than what is available in the back side 
of 2955 R. Do you mean to open up the box and then the 8 ports will be visible?

We are using following commands on the software side:


usrp->set_rx_lo_freq(frequncy+(sampleRate/2),"LO1",2);
std::coutset_rx_lo_source("internal",usrp->ALL_LOS,2);
usrp->set_rx_lo_export_enabled(true,usrp->ALL_LOS,2);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",3);
usrp->set_rx_lo_source("companion",usrp->ALL_LOS,3);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",0);
usrp->set_rx_lo_source("external",usrp->ALL_LOS,0);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",1);
usrp->set_rx_lo_source("external",usrp->ALL_LOS,1);

Also you mentioned using "set_time_unknown_pps()" command so is this command 
along with the above commands enough in the software side or some more commands 
are there for LO sharing? If so what are those?


That *should* be enough.

I'm going to recommend that you look at this document, and the related code:

https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2

Which uses TwinRx with LO sharing in a coherent receiver setup.


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

[USRP-users] vita_time in noc_shell and axi_wrapper

[Xingjian Chen via USRP-users]

Dear all,
 What is the difference for vita_time between the vita_time in noc_shell and 
axi_wrapper in a RFNOC module?
I noticed that there is vita_time input for noc_shell, but also a vita_time can 
be included in the axi_wrapper input s_axis_data_tuser. I guess that for 
noc_shell, the vita_time input is for the universal synchronization time 
between modules. And the vita_time in the axi_wrapper input s_axis_data_tuser 
is for schedule a future command. For example, I can add a delay time for 
transmission in the header in s_axis_data_tuser in siggen rfnoc example.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

[Brian Padalino via USRP-users]

On Tue, Apr 9, 2019 at 12:13 PM Tillson, Bob (US) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I see this a lot with short waveforms as it is much more impactful.
>
> When you submit samples, there are previous samples within the buffer
> (there always are) and the "entire" waveform doesn’t always come out, seems
> like hysteresis.  I usually prepend and postpend samples and do some timing
> bookkeeping to account for added samples.
>
>
There's group delay within the HB filters and the CIC filters that need to
be flushed out with appended zeroes.

Have you tried appending zeroes to the end of your short burst to flush the
filter states?

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

Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

[Marcus D. Leech via USRP-users]

On 04/09/2019 12:12 PM, Tillson, Bob (US) via USRP-users wrote:

I see this a lot with short waveforms as it is much more impactful.

When you submit samples, there are previous samples within the buffer (there always are) 
and the "entire" waveform doesn’t always come out, seems like hysteresis.  I 
usually prepend and postpend samples and do some timing bookkeeping to account for added 
samples.
Considering *only* the filter lengths, unless your sample buffer is an 
exact multiple of the filter length, there's no way to NOT produce some 
kind of
  transient at one end or the other.  That transient will inevitably be 
some combination of digital artifacts, and analog ringing when you slam the

  transmitter PA on and off--hams call that analog effect "key click".

My understanding (and I've never designed one myself) is that 
teensy-burst transmitters have all of the hardware carefully tuned to the
  problem at hand.   Doing rapid teensy-burst on a generic SDR platform 
may require some carefully-considered workarounds and
  even some re-thinking of the software architecture to mitigate some 
of these inherent "quirks".






-Original Message-
From: USRP-users  On Behalf Of Michael R. 
Freedman via USRP-users
Sent: Tuesday, April 9, 2019 11:34 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Hello,


I am doing timed streaming.  It appears to me that there are several "zero" 
samples getting to the DAC prior to my waveform and as a result, my waveform is being 
truncated.  Has anyone else seen this?


Mike


___
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] XG firmware and packet routing

[Minutolo, Lorenzo (389I) via USRP-users]

Hi All,

I'm Using the X300 with the XG firmware from UHD 3.14, connected to the host pc 
via primary and secondary addresses.

Since I'm using four different streamer I'd like to be able to tell to each 
streamer which address to use. Is that possible?


Thanks,

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

Re: [USRP-users] (no subject)

[John Medrano via USRP-users]

Thank you.

Using:

set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
-Wl,--no-whole-archive)
target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
your libs...>)

We are able to use our controller.

On Mon, Apr 8, 2019 at 11:52 AM Nick Foster  wrote:

> OK, I looked further into it. UHD registers out-of-tree block controllers
> using the UHD_RFNOC_BLOCK_REGISTER macro, which under the hood creates a
> static function and a fixture which calls it before main(). Problem is,
> when linking your out-of-tree executable, the linker sees that the static
> fixture is never explicitly called from your program, and it optimizes it
> out. So your block is never getting registered.
>
> There's a number of ways to fix it. I don't know how UHD does it
> internally. If you are linking your library statically, you can do
> something like the following in the CMakeLists.txt for the application (not
> the library):
>
> set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
> -Wl,--no-whole-archive)
> target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
> your libs...>)
>
> Using --whole-archive will force the linker to include all the contents of
> your custom static lib in the application. This includes the static
> constructor.
>
> If you're linking dynamically, this may or may not be a problem for you.
> If it is, you can do something like
> set_target_properties(rfnoc_myapp PROPERTIES LINK_WHAT_YOU_USE TRUE)
>
> ...which sets the -Wl,--no-as-needed linker flag, indicating to the linker
> that it should include dynamic libraries that aren't explicitly called.
> This isn't a great solution as it can result in linking to libraries which
> really aren't used.
>
> You can debug this approach by calling the UHD_STATIC_BLOCK macro in your
> library and just having it print something to stdout. If you don't see the
> print in your application, it's not linking static objects correctly.
>
> Nick
>
> On Mon, Apr 8, 2019 at 8:24 AM John Medrano 
> wrote:
>
>> Hello,
>>
>> We have verified that library is being linked.
>>
>> When we run  nm  | grep 
>>
>> We see the following:
>> 00030310 W _ZNK3uhd7device314get_block_ctrlINS_5rfnoc19> name>_block_ctrlEEEN5boost10shared_ptrIT_EERKNS2_10block_id_tE
>> 0023d6e0 V _ZTIN3uhd5rfnoc19_block_ctrlE
>> 00034b00 V _ZTSN3uhd5rfnoc19_ctrlE
>>
>> We continue to get same error.
>>
>> We have several blocks and we tried with all of them with same result.
>>
>>
>> On Wed, Mar 27, 2019 at 4:36 PM Nick Foster  wrote:
>>
>>> Make very sure that your program is actually linking in the library
>>> correctly. Linkers are weird and their interaction with build systems is
>>> often unpredictable and sometimes perverse. Find the symbols in the
>>> compiled library with nm and see that they aren't undefined. Use make
>>> VERBOSE=1 to see the library actually being used.
>>>
>>> Nick
>>>
>>> On Wed, Mar 27, 2019 at 2:55 PM John Medrano 
>>> wrote:
>>>
 Thank you for the response.

 I have added to CMakeList.txt:

 find_library(SLADEW_LIB gnuradio-SLADEW)
 if(NOT SLADEW_LIB)
   message(FATAL_ERROR "SLADEW library not found")
 endif()

 add later I add:

 target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES} ${Boost_LIBRARIES}
 ${SLADEW_LIB})

 It compiles fine but I still get same messages on start up.

 Please advise:
 John


 On Wed, Mar 27, 2019 at 3:00 PM Nick Foster 
 wrote:

> Your program needs to be linked against the library which your custom
> block controller is compiled into, if in fact your block is using a custom
> block controller.
>
> uhd_usrp_probe and the other UHD utilities aren't linked against the
> custom library. This isn't generally a problem since the utilities and
> examples don't make use of your custom block.
>
> Nick
>
> On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello,
>>
>> We have a custom RFNOC block that we have created. When we using
>> GNURadio/Python everything works fine. When follow the examples in
>> uhd/host/examples and generate an executable using C++, we get an error 
>> on
>> execution.
>>
>> We noticed that on start up the python program has no issue locating
>> controllers for all our custom blocks (FreqMod):
>>
>> 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux;
>> GNU C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
>> 2019-Mar-27
>> 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300 
>> initialization
>> sequence...
>> 2019-Mar-27
>> 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
>> size: 1472 bytes.
>> 2019-Mar-27
>> 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio 1x clock: 
>> 200
>> MHz
>> 2019-Mar-27
>> 13:52:

Re: [USRP-users] Stuck spinning in zero_copy_recv thread.

[Michael R. Freedman via USRP-users]

I believe this is definitely supported.  From what I've read, each radio 
can have it's own streamer.  It works great most of the time.  In fact I 
don't remember seeing any of this issue until I went to the latest 
revision of the library.



Mike


On 04/09/2019 01:40 PM, Marcus D. Leech via USRP-users wrote:

On 04/09/2019 01:19 PM, Michael R. Freedman via USRP-users wrote:

Hello,


X310 with UBX boards, individual RX streamers per channel. MultiUSRP 
with either 4 or 6 channels.  Occasionally one or two channels get 
stuck in the zero_copy_recv spinning at 100% of the CPU.  When trying 
to shut down the program, it stays stuck in that thread and has to be 
killed.  Ideas?



Mike
I don't think it was ever intended that individual streamers would be 
created for a multi-channel multi-usrp object.  I'm not certain that 
it working
  at all is "design intent".   It has always been the case in the code 
that I've been involved with, and examples "out there" that a 
multi-channel
  multi-usrp object has its data-flow contained within a multi-channel 
streamer.




___
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] Stuck spinning in zero_copy_recv thread.

[Marcus D. Leech via USRP-users]

On 04/09/2019 01:19 PM, Michael R. Freedman via USRP-users wrote:

Hello,


X310 with UBX boards, individual RX streamers per channel. MultiUSRP 
with either 4 or 6 channels.  Occasionally one or two channels get 
stuck in the zero_copy_recv spinning at 100% of the CPU.  When trying 
to shut down the program, it stays stuck in that thread and has to be 
killed.  Ideas?



Mike
I don't think it was ever intended that individual streamers would be 
created for a multi-channel multi-usrp object.  I'm not certain that it 
working
  at all is "design intent".   It has always been the case in the code 
that I've been involved with, and examples "out there" that a multi-channel
  multi-usrp object has its data-flow contained within a multi-channel 
streamer.




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

Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

[Marcus D. Leech via USRP-users]

On 04/09/2019 12:15 PM, Michael R. Freedman via USRP-users wrote:
As a bandaid I have padded the trailing end of the waveform with 17 
samples.  Seems to be the same for 1MHz and 2MHz sample rate. In 
reality, I would think that the first sample should hit the DAC at the 
commanded time.  Or at minimum, the samples that are gated into the 
DAC always start at the first sample.  Using AXI is there not away to 
place a timestamp on each sample so that the gating logic so the DAC 
could leverage that? Or maybe a valid sample flag?


Mike
It has always been that case, AFAIR, that the timestamp on TX samples 
applies to the time the samples are launched towards the DUC chain, rather
  than the time the samples are expected to exit the DUC chain. Since 
the DUC chain has variable latency (depending on effective interpolation
  ratio), and the DUC filters will change from time to time to meet 
signal-quality goals as the product matures, I think it was felt to be 
easier
  and consume less FPGA footprint to handle timestamps in the way that 
they're handled.


But I was not a party to any such decision process within Ettus 
engineering, so there may well be even-deeper reasons that it is done the

  way it is done.





On 04/09/2019 12:12 PM, Tillson, Bob (US) wrote:

I see this a lot with short waveforms as it is much more impactful.

When you submit samples, there are previous samples within the buffer 
(there always are) and the "entire" waveform doesn’t always come out, 
seems like hysteresis.  I usually prepend and postpend samples and do 
some timing bookkeeping to account for added samples.


-Original Message-
From: USRP-users  On Behalf Of 
Michael R. Freedman via USRP-users

Sent: Tuesday, April 9, 2019 11:34 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Hello,


I am doing timed streaming.  It appears to me that there are several 
"zero" samples getting to the DAC prior to my waveform and as a 
result, my waveform is being truncated.  Has anyone else seen this?



Mike


___
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] Stuck spinning in zero_copy_recv thread.

[Michael R. Freedman via USRP-users]

Hello,


X310 with UBX boards, individual RX streamers per channel. MultiUSRP 
with either 4 or 6 channels.  Occasionally one or two channels get stuck 
in the zero_copy_recv spinning at 100% of the CPU.  When trying to shut 
down the program, it stays stuck in that thread and has to be killed.  
Ideas?



Mike


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

Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

[Michael R. Freedman via USRP-users]

Is there no sideband data attached to each sample as it goes through the 
pipeline?  Even given decimation/interpolation?


Mike


On 04/09/2019 12:22 PM, Tillson, Bob (US) wrote:

Would be nice if this were possible, but there are filters inbetween and they 
all have memory that is not possible to predict the values they contain because 
they are not zero'd upon tx startup and with different sampling rates and 
interpolation what is more annoying is they have different lengths based upon 
the sampling rate.

-Original Message-
From: Michael R. Freedman 
Sent: Tuesday, April 9, 2019 12:16 PM
To: Tillson, Bob (US) ; usrp-users 
(usrp-users@lists.ettus.com) 
Subject: Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


As a bandaid I have padded the trailing end of the waveform with 17 samples.  
Seems to be the same for 1MHz and 2MHz sample rate. In reality, I would think 
that the first sample should hit the DAC at the commanded time.  Or at minimum, 
the samples that are gated into the DAC always start at the first sample.  
Using AXI is there not away to place a timestamp on each sample so that the 
gating logic so the DAC could leverage that?  Or maybe a valid sample flag?

Mike


On 04/09/2019 12:12 PM, Tillson, Bob (US) wrote:

I see this a lot with short waveforms as it is much more impactful.

When you submit samples, there are previous samples within the buffer (there always are) 
and the "entire" waveform doesn’t always come out, seems like hysteresis.  I 
usually prepend and postpend samples and do some timing bookkeeping to account for added 
samples.

-Original Message-
From: USRP-users  On Behalf Of
Michael R. Freedman via USRP-users
Sent: Tuesday, April 9, 2019 11:34 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Hello,


I am doing timed streaming.  It appears to me that there are several "zero" 
samples getting to the DAC prior to my waveform and as a result, my waveform is being 
truncated.  Has anyone else seen this?


Mike


___
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] Propagation delay in TxStreamer X310 3.14.0.0

[Tillson, Bob (US) via USRP-users]

Would be nice if this were possible, but there are filters inbetween and they 
all have memory that is not possible to predict the values they contain because 
they are not zero'd upon tx startup and with different sampling rates and 
interpolation what is more annoying is they have different lengths based upon 
the sampling rate.

-Original Message-
From: Michael R. Freedman  
Sent: Tuesday, April 9, 2019 12:16 PM
To: Tillson, Bob (US) ; usrp-users 
(usrp-users@lists.ettus.com) 
Subject: Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


As a bandaid I have padded the trailing end of the waveform with 17 samples.  
Seems to be the same for 1MHz and 2MHz sample rate. In reality, I would think 
that the first sample should hit the DAC at the commanded time.  Or at minimum, 
the samples that are gated into the DAC always start at the first sample.  
Using AXI is there not away to place a timestamp on each sample so that the 
gating logic so the DAC could leverage that?  Or maybe a valid sample flag?

Mike


On 04/09/2019 12:12 PM, Tillson, Bob (US) wrote:
> I see this a lot with short waveforms as it is much more impactful.
>
> When you submit samples, there are previous samples within the buffer (there 
> always are) and the "entire" waveform doesn’t always come out, seems like 
> hysteresis.  I usually prepend and postpend samples and do some timing 
> bookkeeping to account for added samples.
>
> -Original Message-
> From: USRP-users  On Behalf Of 
> Michael R. Freedman via USRP-users
> Sent: Tuesday, April 9, 2019 11:34 AM
> To: usrp-users@lists.ettus.com
> Subject: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0
>
> *** WARNING ***
> EXTERNAL EMAIL -- This message originates from outside our organization.
>
>
> Hello,
>
>
> I am doing timed streaming.  It appears to me that there are several "zero" 
> samples getting to the DAC prior to my waveform and as a result, my waveform 
> is being truncated.  Has anyone else seen this?
>
>
> Mike
>
>
> ___
> 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] Propagation delay in TxStreamer X310 3.14.0.0

[Michael R. Freedman via USRP-users]

As a bandaid I have padded the trailing end of the waveform with 17 
samples.  Seems to be the same for 1MHz and 2MHz sample rate. In 
reality, I would think that the first sample should hit the DAC at the 
commanded time.  Or at minimum, the samples that are gated into the DAC 
always start at the first sample.  Using AXI is there not away to place 
a timestamp on each sample so that the gating logic so the DAC could 
leverage that?  Or maybe a valid sample flag?


Mike


On 04/09/2019 12:12 PM, Tillson, Bob (US) wrote:

I see this a lot with short waveforms as it is much more impactful.

When you submit samples, there are previous samples within the buffer (there always are) 
and the "entire" waveform doesn’t always come out, seems like hysteresis.  I 
usually prepend and postpend samples and do some timing bookkeeping to account for added 
samples.

-Original Message-
From: USRP-users  On Behalf Of Michael R. 
Freedman via USRP-users
Sent: Tuesday, April 9, 2019 11:34 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Hello,


I am doing timed streaming.  It appears to me that there are several "zero" 
samples getting to the DAC prior to my waveform and as a result, my waveform is being 
truncated.  Has anyone else seen this?


Mike


___
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] Propagation delay in TxStreamer X310 3.14.0.0

[Michael R. Freedman via USRP-users]

X310 with UBX front ends.


Mike


On 04/09/2019 12:07 PM, Brian Padalino wrote:
On Tue, Apr 9, 2019 at 11:46 AM Michael R. Freedman 
mailto:mfreed...@ll.mit.edu>> wrote:


I'm generating samples at 2MHz.

What Ettus radio are you using?

Brian


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

Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

[Tillson, Bob (US) via USRP-users]

I see this a lot with short waveforms as it is much more impactful.

When you submit samples, there are previous samples within the buffer (there 
always are) and the "entire" waveform doesn’t always come out, seems like 
hysteresis.  I usually prepend and postpend samples and do some timing 
bookkeeping to account for added samples.

-Original Message-
From: USRP-users  On Behalf Of Michael R. 
Freedman via USRP-users
Sent: Tuesday, April 9, 2019 11:34 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Hello,


I am doing timed streaming.  It appears to me that there are several "zero" 
samples getting to the DAC prior to my waveform and as a result, my waveform is 
being truncated.  Has anyone else seen this?


Mike


___
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] Propagation delay in TxStreamer X310 3.14.0.0

[Brian Padalino via USRP-users]

On Tue, Apr 9, 2019 at 11:46 AM Michael R. Freedman 
wrote:

> I'm generating samples at 2MHz.
>
What Ettus radio are you using?

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

Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

[Michael R. Freedman via USRP-users]

I'm generating samples at 2MHz.


Mike


On 04/09/2019 11:45 AM, Brian Padalino wrote:
On Tue, Apr 9, 2019 at 11:35 AM Michael R. Freedman via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hello,


I am doing timed streaming.  It appears to me that there are several
"zero" samples getting to the DAC prior to my waveform and as a
result,
my waveform is being truncated.  Has anyone else seen this?


Are you going through any of the interpolation filters or producing 
samples at the target DAC rate for your system?


Brian


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

Re: [USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

[Brian Padalino via USRP-users]

On Tue, Apr 9, 2019 at 11:35 AM Michael R. Freedman via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
> I am doing timed streaming.  It appears to me that there are several
> "zero" samples getting to the DAC prior to my waveform and as a result,
> my waveform is being truncated.  Has anyone else seen this?
>

Are you going through any of the interpolation filters or producing samples
at the target DAC rate for your system?

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

[USRP-users] Propagation delay in TxStreamer X310 3.14.0.0

[Michael R. Freedman via USRP-users]

Hello,


I am doing timed streaming.  It appears to me that there are several 
"zero" samples getting to the DAC prior to my waveform and as a result, 
my waveform is being truncated.  Has anyone else seen this?



Mike


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

Re: [USRP-users] PPS to custom RFNoC block

[Leandro Echevarría via USRP-users]

Hey Cherif,

I have no experience with this whatsoever, but taking the X310 code as
an example, I see that PPS is an input signal to x300_core.v, where
the RFNoC blocks are instantiated. I'd assume you could route this
directly to your custom block.

Regards,

Leo.

On Tue, Apr 9, 2019 at 6:32 AM Cherif Diouf via USRP-users
 wrote:
>
> Hello guys,
>
>
> I would like to know how to directly feed my custom
>
> HW RfNoC block by the external PPS signal.
>
>
> Many thanks
>
> Cherif
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



-- 
Leandro Echevarría

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

[USRP-users] FPGA build errors

[Scott Mullin via USRP-users]

Hello,

We have several ettus transceivers and I typically have to build different
images for different users of the transceivers.  However I run into an
error when I am building an FPGA image using uhd_image_builder.  The build
will fail if there are errors in noc blocks which are not in the current
build image?  So for instance if i build an image with the fft block then,
while modifying the fft block for another user, I start to build another
image with ddc, duc, and addsub, the build will error out until I fix all
of my errors in the fft block?   Is there a buffer or cache that stores
previous builds?  How can I clean this, for lack of a better tern, in
between builds?

Thank you in advance.

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

[USRP-users] PPS to custom RFNoC block

[Cherif Diouf via USRP-users]

Hello guys,


I would like to know how to directly feed my custom

HW RfNoC block by the external PPS signal.


Many thanks

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

Re: [USRP-users] Changing sample rate while running.

[Fabian Schwartau via USRP-users]

Hi,

maybe this is related to a very similar problem I had back a few month 
ago. Here is the thread:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-July/057308.html

The outcome was basically that the software does not support timed 
sample rate switching. I had to wait for every command to be finished, 
switch the samplerate and restart everything. But maybe that is a bit 
different from your situation as you are not looking for timed commands.


Best regards,
Fabian

Am 08.04.2019 um 17:54 schrieb Chance Tarver via USRP-users:

Hi all,

I am working on a project where I need to change the sampling rate 
occasionally while running my application.


At an event where I need to change the sampling rate, I am currently 
calling the following function:

|set_tx_rate(new_rate, channel)|

The master clock is always set to 30.72MHz and the TX bandwidth is set 
to 20MHz.


When the change occurs, it seems that I am not getting the new sampling 
rate on the spectrum analyzer. I know these sort of changes in sampling 
rates can be weird and depend on how the various clocks are set.


Is there a recommended procedure / series of steps for a change in 
sampling rate to take effect?


I appreciate any guidance.

Thanks,
Chance Tarver
Rice University

___
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] UBX coherence between TX and RX

[Piotr Krysik via USRP-users]

Hi Mike,

Let's keep the discussion on the mailing list. I attach the scripts as
they are quite small. There is however a data folder with two 4MB files
containing noise in complex short format. The version of the archive
with those files is here:
https://app.box.com/s/xfpwro8wybog4f1yo1l6yh665tg4sx0r

First you run:
./record.sh

then:
./show_figures.m

(you need to have octave installed for the second script).

Best Regards,
Piotr Krysik

W dniu 08.04.2019 o 18:30, Michael R. Freedman pisze:
> That would be wonderful if I could get your scripts to run.
>
>
> Thanks a bunch for the info!
>
>
> Mike
>
>
> On 04/08/2019 09:56 AM, Piotr Krysik via USRP-users wrote:
>> Hi all,
>>
>> I looked at this thread and it reminded me of something.
>>
>> Once we purchased few X310 with UBX160 daughter-boards.
>>
>> One of them had some frequency offset on Tx channel, that decreased over
>> time it was running, but very slowly.
>>
>> The daughter-board was then replaced by National Intruments (after some
>> adventures ;) ). The replacement one had exactly the same issue so it
>> was also replaced. The next one was ok. So it seemed it was some
>> manufacturing issue with UBX.
>>
>> I don't know if it's the same issue (i.e. due to lack of data), but I
>> attach part of the report that was sent to National Instruments:
>> -phase offset of the received signal in relation to digital waveform for
>> a single X310 with UBX160 for all TX and RX combinations:
>> https://imgur.com/a/ODBtT4o
>> -schematic:
>> https://imgur.com/a/si9fJZp
>>
>> I got also scripts that were used for recording and plotting that
>> figure. If you are interested I can post it somewhere.
>>
>> What seems different from situation here is that for us it seemed the
>> effect wasn't depending on frequency (but I didn't do any extensive
>> tests and might not remember).
>>
>> -- 
>> Best Regards,
>> Piotr Krysik
>>
>> W dniu 07.04.2019 o 03:00, Freedman, Michael - 1008 - MITLL via
>> USRP-users pisze:
>>> I have switched and am currently running the release 3.14.0.0
>>>
>>> Sent from my iPhone
>>>
>>> On Apr 6, 2019, at 8:58 AM, Marcus D. Leech >> > wrote:
>>>
>>> On 04/05/2019 11:43 AM, Michael R. Freedman wrote:
 Hello,


 If I remove the DSP from the equation by setting the DSP tuning
 policy to manual and assigning it to zero, I am coherent from tx to
 rx on all frequencies.  I'm now beginning to think that the DSP is
 doing it's tuning differently for tx and rx.  Or there is an
 accumulated error in opposite directions for both.  Thoughts?


 Leaving the DSP to zero is not a good solution however as there is
 too much LO leakage.


>>> Could you try UHD 3.14.0.0?
>>>
>>> I think that you're using the -rc3 version at the moment.
>>>
>>>
 Mike


 On 03/27/2019 04:58 PM, Marcus D. Leech wrote:
> On 03/27/2019 04:48 PM, Michael R. Freedman wrote:
>> This is on a single UBX card within a single USRP.
>>
>>
>> ./uhd_usrp_probe --args=addr=192.168.40.100
>> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
>> UHD_3.14.0.0-0-unknown
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Maximum frame size: 8000 bytes.
>> [INFO] [X300] Radio 1x clock: 200 MHz
>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>> 0xF1F0D000)
>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s)
>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1294 MB/s)
>> [INFO] [0/Radio_0] Initializing block control (NOC ID:
>> 0x12AD1001)
>> [INFO] [0/Radio_1] Initializing block control (NOC ID:
>> 0x12AD1001)
>> [INFO] [0/DDC_0] Initializing block control (NOC ID:
>> 0xDDC0)
>> [INFO] [0/DDC_1] Initializing block control (NOC ID:
>> 0xDDC0)
>> [INFO] [0/DUC_0] Initializing block control (NOC ID:
>> 0xD0C0)
>> [INFO] [0/DUC_1] Initializing block control (NOC ID:
>> 0xD0C0)
>>    _
>>   /
>> |   Device: X-Series Device
>> | _
>> |    /
>> |   |   Mboard: X310
>> |   |   revision: 6
>> |   |   product: 30410
>> |   |   mac-addr0: 00:80:2f:0a:ff:98
>> |   |   mac-addr1: 00:80:2f:0a:ff:99
>> |   |   gateway: 192.168.10.1
>> |   |   ip-addr0: 192.168.10.100
>> |   |   subnet0: 255.255.255.0
>> |   |   ip-addr1: 192.168.20.100
>> |   |   subnet1: 255.255.255.0
>> |   |   ip-addr2: 192.168.30.100
>> |   |   subnet2: 255.255.255.0
>> |   |   ip-addr3: 192.168.40.100
>> |   |   subnet3: 255.255.255.0
>> |   |   serial: F5BE45
>> |   |   FW Version: 6.0
>> |   |   FPGA Version: 35.1
>> |   |   FPGA git hash: 4c165a5
>> |   |   RFNoC capable: Yes
>> |   |
>> |   |   Time sources:  in