Re: [USRP-users] Creating RFNOC block that changes stream rate

[Jon Pendlum via USRP-users]

Hi Andrew,

You'll need to have a Xilinx USB programmer (or Digilent JTAG-HS3 probably
works too), purchase this kit https://www.ettus.com/product/details/E-JTAG-4,
and follow these instructions:
https://www.ettus.com/content/files/E-Series_JTAG-AVR_Cable_Getting_Started_Guide_.pdf.
For setting up the ILA and debugging, see:
https://kb.ettus.com/Debugging_FPGA_images.

Jonathon

On Thu, Dec 20, 2018 at 7:47 AM Andrew Danowitz 
wrote:

> Hi John,
>
> Is there any documentation on using the ILA on an e310 that's running
> gnuradio directly?
>
> Thanks,
> Andrew
>
> On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum  wrote:
>
>> Hi Andrew,
>>
>> Have you tried using Chipscope to see where the issue is at in your code?
>> You want to look at the tvalid and tready AXI stream control signals to
>> pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0). Once
>> you know where the stall is located, I can provide more advice.
>>
>> Jonathon
>>
>> On Wed, Dec 19, 2018 at 8:20 AM Andrew Danowitz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Thanks for the reply. I do set simple_mode and I propagate tuser into
>>> and out of axi_rate_change the same way noc_block_ddc does. I also have my
>>> block running properly in Vivado simulation. Is there anything else I
>>> should check? I also included axi_tag_time. Could that be causing an issue?
>>>
>>> Thanks!
>>> Andrew
>>>
>>> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>>>
 Hi Andrew,

 Quick thoughts:
 - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
 - Are you propagating tuser into and out of the axi_rate_change block?

 The axi_rate_change block updates tuser, which the axi_wrapper uses to
 create output packets when SIMPLE_MODE is disabled.

 Also, have you run in a simulation testbench? Simulation should be able
 to expose these issues before targetting hardware to make debugging a bit
 easier.

 EJ



 On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to create an rfnoc block that takes in a stream of data at
> Sample rate n, does some processing to turn i-q values into real samples,
> and outputs data at a rate of n/2 by packing real values into both i and q
> channels of the output stream. I've tried to incorporate the
> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
> whenever I try to run it I keep getting a timeout error. If I take out the
> channel packing block and keep the rate n-to-n, the module works fine.
>
> Does anyone have any advice?
>
> Thanks,
> Andrew
>
> --
> Information contained, linked, or attached to this email and all
> verbal communications from WhiteFox Defense to your entity in the prior 30
> days constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in 
> error,
> please promptly notify i...@whitefoxdefense.com and destroy all
> copies of the message and any attachments. This email and attachments may
> contain technical data as defined in the International Traffic In Arms
> Regulations (ITAR) 22 CFR 120.10 or the Export Administration Regulations
> (EAR) 15 CFR Parts 730 – 780.  Export of this material may be controlled 
> by
> these regulations and may not be exported or transferred to non-U.S.
> persons without prior written approval from the U.S. government.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

>>> --
>>> Information contained, linked, or attached to this email and all verbal
>>> communications from WhiteFox Defense to your entity in the prior 30 days
>>> constitute proprietary and confidential information unless otherwise
>>> indicated and is therefore subject to obligations in any executed
>>> confidentiality agreements. Further, this email is intended solely for the
>>> use of the individual or entity to whom they are addressed. If you are not
>>> the intended recipient and this message has been addressed to you in error,
>>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>>> of the message and any attachments. This email and attachments may contain
>>> technical data as defined in the International Traffic In Arms Regulations
>>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>>> Parts 730 – 780.  Export of this material m

Re: [USRP-users] Faster way to send asynchronous data to RFNoC block

[Brian Padalino via USRP-users]

On Wed, Dec 19, 2018 at 6:22 PM J M  wrote:

> Some of that makes sense to me.  Do you know of an open source example
> where something similar to this is done?
>

No, but it shouldn't be too bad to try and simulate.  Make a top block with
2 sets of AXI streaming associated with bus_clk, then instantiate a
noc_shell for each port each with their own ID to it.

Then the one port can be associated with RAM initialization, and the other
port can be for streaming data.

I'm sure it'll potentially expose some strange interactions between things,
but one problem at a time, right?

Brian

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

Re: [USRP-users] 2x N200 GPSDO PPS relative drift

[Michael West via USRP-users]

Hi Stephan,

I'm not sure if moving the power resolved your issue, but I wanted to
follow up now that we have completed our root cause analysis.  The GPSDO
requires a minimum of 5.7V to retain accuracy and the voltage on J509 is
dropping below that during TX and/or RX.  The resolution is to first move
the GPSDO power from J509 to J102 on the motherboard.  If that does not
resolve the issue, add solder to between the center pin and back plate of
the front panel power connector (J101).

We are putting in place RMA rework instructions, so you may contact
supp...@ettus.com to arrange for an RMA to have the rework done if you are
not comfortable or capable of doing it yourself.

Best regards,
Michael

On Fri, Nov 16, 2018 at 5:47 AM Stephan Esterhuizen <
stephan.esterhui...@spire.com> wrote:

> Thanks for the tip Michael. I'm on travel at the moment, and will try this
> next week when I get back to the lab. I'll report my findings to mailing
> list.
>
> Cheers
>
> Stephan
>
> On Wed, Nov 14, 2018 at 1:09 AM Michael West 
> wrote:
>
>> Hi Stephan,
>>
>> Try moving the GPSDO power from the J509 connector to the J102 connector
>> on the N200 motherboard.  J102 is 6V AUX power and does not sag when
>> running.  The provided cable is a little short, so you will have to get
>> creative.  Give that a try and let us know if it solves the problem.
>>
>> Regards,
>> Michael
>>
>> On Sat, Nov 10, 2018 at 9:33 AM Stephan Esterhuizen via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Robin,
>>>
>>> Thank you for the reply. I have debugged the problem more and realized
>>> two issues.
>>>
>>> 1) The massive drift of 14 microseconds/second was due me using a 6V, 2A
>>> brick supply. This is my fault! After switching it out for a 3A supply, I'm
>>> able to get the GPSDO to lock (GPS_SERVO message returns 6 for lock status
>>> field)
>>> 2) Once you start collecting data, GPSDO PPS & 10 MHz start drifting
>>> from UTC. As mentioned, this is probably due to a voltage sag on the 6V
>>> supply for the Firefly GPSDO.
>>>
>>> For issue 2, I measured the nominal voltage to GPSDO (USRP N200 J509) to
>>> be 5.678V (+-2mV), then once I start a data collection, the minimum voltage
>>> I see is 5.532V, then after a few seconds of data collection it reaches a
>>> "steady state" of 5.545 V. This small change of (5.678-5.545 V) 133 mV is
>>> enough to give the PPS a drift of about 5-8 nsec/second. Eventually the
>>> GPSDO feedback loop catches this and steers it back to something more
>>> acceptable. For reference, the voltage at the input to N200 (J101) is
>>> 5.901V+-5mV when idle and collecting samples.
>>>
>>> This slight deviation of < 100 nanoseconds  due to voltage change is
>>> fine for my application, I realized I can just read back the GPS_SERVO
>>> sensor and get the actual offset from UTC to correct any timestamps.
>>>
>>> Regards
>>>
>>> Stephan
>>>
>>>
>>> On Fri, Nov 9, 2018 at 5:09 PM Robin Coxe  wrote:
>>>
 Hi Stephan.  Your issue looks similar to one that has been previously
 reported.   The Hardware Sustaining Engineering team is currently
 investigating.

 Would it be possible for you to try powering the GPSDO module from a
 lab supply instead of plugging it in to the N210 motherboard and checking
 if your issue still persists?
 That would help us determine if you are experiencing the same problem.
 Another helpful measurement would be to measure the voltage drop of the 6V
 wall wart when the GPSDO IS powered by the N210 motherboard.

 We will keep you and list updated on the progress of the investigation.

 -Robin


 On Fri, Nov 9, 2018 at 3:06 AM Stephan Esterhuizen via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hi All,
>
> I have two N200 USRPs with Jackson-Labs Firefly 1A GPSDO. I'm doing a
> very basic test, where I have a common active GPS antenna split 2 ways
> (with DC block on one N200 GPS antenna port). I then watch the 1PPS from
> each GPSDO on a scope, and unfortunately see the PPS drift by as much as 
> 14
> microseconds per second relative to each other. When this offset reaches
> about 1.5-2.0 milliseconds, I see the PPS relative offset "snap" down to a
> few micro seconds error, but then they immediately start drifting apart
> again.
>
> The N200 GPSDO reports they're locked. I wrote some quick python code
> to query sensors:
>
> --
> FIRST N200:
> --
> [INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware
> Rev 0.929
> [INFO] [USRP2] Setting references to the internal GPSDO
> GPS lock status: locked
> GPS_GPGGA:
> $GPGGA,095011.00,.x,N,.x,E,1,10,0.9,320.7,M,46.9,M,,*6C
> GPS_SERVO: 18-11-09 3888 94089 21.81 2.08E-11 13 10 6 0x0
> GPS epoch time: 1541757012 seconds
> Ref: locked
>
>
> --
> SECOND

Re: [USRP-users] synchronizing multiple USRP N310

[Michael West via USRP-users]

Hi Florian,

The device arguments are "clock_source" and "time_source".  I noticed in
your command you had them as "clock_src" and "time_src".  That may be the
source of the problem.

Regards,
Michael

On Mon, Dec 10, 2018 at 11:33 AM Florian Kaltenberger via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear Nate,
>
> no it says something like this is not supported with the N310 and I should
> pass it using the args options. Sorry, I don't have access to the N310
> right now, so I can't give you the exact message, but I have tried that.
>
> Florian.
> On 10/12/2018 19:00, Nate Temple wrote:
>
> Hi Florian,
>
> If you pass the arg  "--ref external" to tx_waveforms, does it resolve
> this frequency offset?
>
>
> https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L62
>
> Regards,
> Nate Temple
>
> On Thu, Dec 6, 2018 at 12:22 AM Florian Kaltenberger via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Marcus,
>>
>> I have measured this with a spectrum analyzer simply by setting markers
>> to the peak of the sinusoid (one marker per measured USRP) and then taking
>> the delta.
>>
>> Could it be that the USRP is ignoring the external reference when used
>> alone? Remember, I am doing the test with one USRP at a time, as the test
>> using multiple USRP simultaneously does not work.
>>
>> Florian.
>> On 06/12/2018 00:29, Marcus Müller wrote:
>>
>> oh! That means 341 ppb frequency error, which *really* shouldn't be
>> happening.
>>
>> I'd like to get some statistics of that error, how are you measuring
>> it?
>>
>> Best regards,
>> Marcus
>>
>> On Wed, 2018-12-05 at 12:55 +0100, Florian Kaltenberger wrote:
>>
>> Sorry typo. I did use a frequency of 3.51GHz.
>>
>>
>> On 5 Dec 2018, at 12:54, Marcus Müller  
>> 
>> wrote:
>>
>> Hi Florian,
>>
>> trying to get my head to understand the order of problems here:
>> Could you try to use a higher frequency (say, --freq 2e9 instead of
>> 3.5e6)?
>> I'd thing 3.51 MHz is out of range for the N310, anyway?
>>
>> Best regards,
>> Marcus
>>
>> On Wed, 2018-12-05 at 11:49 +0100, Florian Kaltenberger via USRP-
>> users
>> wrote:
>>
>> So I can confirm that there is a frequency offset between the two
>> USRP N310s when using only an octoclock (10MHz + PPS) to
>> synchronize.
>> I have measured with the tx_waveforms program
>> ./tx_waveforms --args
>> "addr=192.168.x.2,time_src=external,clock_src=external,master_clo
>> ck_r
>> ate=122.88e6" --rate 122.88e6 --freq 3.51e6 --wave-type SINE --
>> wave-
>> freq 10e6 --gain 100
>> on the first USRP N310 (x=10) and then on the other (x=20). There
>> is
>> an offset of 1200Hz between the peaks of the sinusoids between
>> the
>> two measurements.
>> Using an external LO didn't change anything either. Unless I need
>> to
>> provide any other arguments in that case?
>> I also tried to do a test where I use both USRPs simultaneously
>> ./tx_waveforms --args
>> "addr0=192.168.10.2,addr1=192.168.20.2,time_src=external,clock_sr
>> c=ex
>> ternal,master_clock_rate=122.88e6" --rate 122.88e6 --freq 3.51e6
>> --
>> wave-type SINE --wave-freq 10e6 --gain 100--channels "0,4"
>> but unfortunately that does not work at all at my testbench
>> (program
>> hangs and no signal transmitted).
>> My UHD version is 3.13.0.2 (UHD_3.13.0.HEAD-0-g0ddc19e5)
>> Any help appreciated.
>> Thanks!
>> Florian.
>>
>>
>> On 04/12/2018 21:29, Florian Kaltenberger via USRP-users wrote:
>> Hi Marcus and Robin,
>> thanks for your answers, this is helpful information. I should
>> add,
>> that I actually tried the synchronization with an octoclock
>> (10MHz
>> + PPS), but it did not give me the expected results, i.e., I
>> saw
>> some residual frequency offsets. But maybe I screwed up at some
>> point. Let me do some more measurements and get back to you on
>> this.
>> Florian.
>>
>>
>> On 04/12/2018 18:57, Marcus D. Leech via USRP-users wrote:
>> On 12/04/2018 10:14 AM, Florian Kaltenberger via USRP-users
>> wrote:
>>
>> Hi there,
>> I just discovered that in addition to the external 10MHz
>> reference in, the USRP N310 also has external local
>> oscilator
>> inputs, one for each daughterboard and each TX/RX. So does
>> that
>> mean that in order to synchronize multiple N310 in
>> frequency,
>> phase, and time, it is no longer sufficient to use an
>> octoclock
>> to provide a 10MHz reference and PPS? If so, at what
>> frequency
>> do you have to drive the external LOs and at what power?
>> Florian.
>>
>>
>> In addition to what Robin posted, I'll observe that the
>> external
>> LO port is an *additional feature* of this device.
>>
>> You should still be able to use the external 10MHz and 1PPS
>> ports
>> the same way you would with a B210 or E310, since the AD9371
>>  front-end chip is similar to the AD9361 chip used in the
>> B210
>> and E310.
>>
>> The thing about synchronizing multiple independent PLL
>> synthesizers, though, compared to a strictly-shared-LO, is
>> that
>> the former will
>>  experience both phase ambiguities, and h

Re: [USRP-users] Faster way to send asynchronous data to RFNoC block

[J M via USRP-users]

Some of that makes sense to me.  Do you know of an open source example
where something similar to this is done?

On Wed, Dec 19, 2018 at 4:30 PM Brian Padalino  wrote:

> On Wed, Dec 19, 2018 at 4:24 PM J M  wrote:
>
>> Potentially, yes the full 200 MHz
>>
>
> Ah, yes.  Then you'd need 2 connections to the crossbar.
>
> If you didn't need all 200MHz, then you could get away with 2 ports off
> the same crossbar connection as well.
>
> I think you would just have each connection be a different block ID that
> shows up, and internally you are just able to share everything.  Externally
> it would look like 2 different blocks, though, and you would have to know
> how to work with them in conjunction with each other.
>
> Does that make sense?
>
> Brian
>
>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Creating RFNOC block that changes stream rate

[Andrew Danowitz via USRP-users]

Hi John,

Is there any documentation on using the ILA on an e310 that's running
gnuradio directly?

Thanks,
Andrew

On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum  wrote:

> Hi Andrew,
>
> Have you tried using Chipscope to see where the issue is at in your code?
> You want to look at the tvalid and tready AXI stream control signals to
> pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0). Once
> you know where the stall is located, I can provide more advice.
>
> Jonathon
>
> On Wed, Dec 19, 2018 at 8:20 AM Andrew Danowitz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Thanks for the reply. I do set simple_mode and I propagate tuser into and
>> out of axi_rate_change the same way noc_block_ddc does. I also have my
>> block running properly in Vivado simulation. Is there anything else I
>> should check? I also included axi_tag_time. Could that be causing an issue?
>>
>> Thanks!
>> Andrew
>>
>> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>>
>>> Hi Andrew,
>>>
>>> Quick thoughts:
>>> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
>>> - Are you propagating tuser into and out of the axi_rate_change block?
>>>
>>> The axi_rate_change block updates tuser, which the axi_wrapper uses to
>>> create output packets when SIMPLE_MODE is disabled.
>>>
>>> Also, have you run in a simulation testbench? Simulation should be able
>>> to expose these issues before targetting hardware to make debugging a bit
>>> easier.
>>>
>>> EJ
>>>
>>>
>>>
>>> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi all,

 I'm trying to create an rfnoc block that takes in a stream of data at
 Sample rate n, does some processing to turn i-q values into real samples,
 and outputs data at a rate of n/2 by packing real values into both i and q
 channels of the output stream. I've tried to incorporate the
 axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
 whenever I try to run it I keep getting a timeout error. If I take out the
 channel packing block and keep the rate n-to-n, the module works fine.

 Does anyone have any advice?

 Thanks,
 Andrew

 --
 Information contained, linked, or attached to this email and all verbal
 communications from WhiteFox Defense to your entity in the prior 30 days
 constitute proprietary and confidential information unless otherwise
 indicated and is therefore subject to obligations in any executed
 confidentiality agreements. Further, this email is intended solely for the
 use of the individual or entity to whom they are addressed. If you are not
 the intended recipient and this message has been addressed to you in error,
 please promptly notify i...@whitefoxdefense.com and destroy all copies
 of the message and any attachments. This email and attachments may contain
 technical data as defined in the International Traffic In Arms Regulations
 (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
 Parts 730 – 780.  Export of this material may be controlled by these
 regulations and may not be exported or transferred to non-U.S. persons
 without prior written approval from the U.S. government.
 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

>>>
>> --
>> Information contained, linked, or attached to this email and all verbal
>> communications from WhiteFox Defense to your entity in the prior 30 days
>> constitute proprietary and confidential information unless otherwise
>> indicated and is therefore subject to obligations in any executed
>> confidentiality agreements. Further, this email is intended solely for the
>> use of the individual or entity to whom they are addressed. If you are not
>> the intended recipient and this message has been addressed to you in error,
>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>> of the message and any attachments. This email and attachments may contain
>> technical data as defined in the International Traffic In Arms Regulations
>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>> Parts 730 – 780.  Export of this material may be controlled by these
>> regulations and may not be exported or transferred to non-U.S. persons
>> without prior written approval from the U.S. government.
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless other

[USRP-users] X310 FPGA IQ Samples

[Alexander Olihovik via USRP-users]

Hi all,

I'm trying to work with IQ data on the X310 right as it leaves the FPGA to
be transmitted, and also as soon as it is received from the daughtercard.
Is "capture_ddrlvds.v" and "gen_ddrlvds.v" the right place to do this?

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

Re: [USRP-users] Faster way to send asynchronous data to RFNoC block

[Brian Padalino via USRP-users]

On Wed, Dec 19, 2018 at 4:24 PM J M  wrote:

> Potentially, yes the full 200 MHz
>

Ah, yes.  Then you'd need 2 connections to the crossbar.

If you didn't need all 200MHz, then you could get away with 2 ports off the
same crossbar connection as well.

I think you would just have each connection be a different block ID that
shows up, and internally you are just able to share everything.  Externally
it would look like 2 different blocks, though, and you would have to know
how to work with them in conjunction with each other.

Does that make sense?

Brian

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

Re: [USRP-users] Faster way to send asynchronous data to RFNoC block

[J M via USRP-users]

Potentially, yes the full 200 MHz

On Wed, Dec 19, 2018 at 4:14 PM Brian Padalino  wrote:

> On Wed, Dec 19, 2018 at 4:06 PM J M  wrote:
>
>> The block is performing some signal processing on incoming samples
>> streaming from a radio block, but the signal processing is based on the
>> data stored in the ram.  It would be ideal to be able to swap out the RAM
>> while the block is streaming, though loading it once at start is better
>> than what we have now.
>>
>> This is a good suggestion, however in the meantime to get it loaded more
>> quickly at the start.  It seems if it was feasible, having a second AXI
>> stream interface would be cleaner, but I don't know if it's possible.
>>
>
> How much data are you processing on the AXI stream?  Is it the full 200MHz
> worth of bandwidth?
>
> Brian
>
>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Faster way to send asynchronous data to RFNoC block

[Brian Padalino via USRP-users]

On Wed, Dec 19, 2018 at 4:06 PM J M  wrote:

> The block is performing some signal processing on incoming samples
> streaming from a radio block, but the signal processing is based on the
> data stored in the ram.  It would be ideal to be able to swap out the RAM
> while the block is streaming, though loading it once at start is better
> than what we have now.
>
> This is a good suggestion, however in the meantime to get it loaded more
> quickly at the start.  It seems if it was feasible, having a second AXI
> stream interface would be cleaner, but I don't know if it's possible.
>

How much data are you processing on the AXI stream?  Is it the full 200MHz
worth of bandwidth?

Brian

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

Re: [USRP-users] Faster way to send asynchronous data to RFNoC block

[J M via USRP-users]

The block is performing some signal processing on incoming samples
streaming from a radio block, but the signal processing is based on the
data stored in the ram.  It would be ideal to be able to swap out the RAM
while the block is streaming, though loading it once at start is better
than what we have now.

This is a good suggestion, however in the meantime to get it loaded more
quickly at the start.  It seems if it was feasible, having a second AXI
stream interface would be cleaner, but I don't know if it's possible.

On Wed, Dec 19, 2018 at 3:00 PM Brian Padalino  wrote:

> On Wed, Dec 19, 2018 at 12:53 PM J M via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> I'm trying to load a RAM inside an RFNoC block, and doing this via
>> register writes takes about a minute and half.
>>
>> So, looking for a quicker way to load up the data from the RAM, thought
>> about a second input to the RFNoC block and source it from the file.  In
>> this way, the RFNoC block would have two inputs, one which would be source
>> from the radio block, and the second from file, but the file would only run
>> through once to load the RAM.
>>
>> Unfortunately, I haven't found any RFNoC examples that have 2 inputs that
>> are not tied together (such as the add/sub block).  Does anyone know of a
>> good example of doing this through RFNoC, or if it is even possible?  Or is
>> there another mechanism for sending a bunch of data across that I'm
>> overlooking?
>>
>
> Can you describe the life cycle of your block for us a little bit in more
> detail?
>
> If you are loading RAM once and only once before starting any streaming,
> you could potentially use a register to choose which mode you are in, and
> then the incoming stream can be pushed to RAM, then the register is cleared
> once you are sure there is nothing more to write into RAM.  Unfortunately,
> without knowing more about your life cycle and how you intend to use the
> block, I am not sure the above suggestion would actually work.
>
> Brian
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 xpr Files

[Alexander Olihovik via USRP-users]

Great, that worked. Thanks Nick!
For anyone else doing this, the following link also helped when
synthesizing the project in Vivado since there were some files missing:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-June/042575.html

Best,
Alex

On Tue, Dec 18, 2018 at 5:25 PM Nick Foster  wrote:

> You can do "make GUI=1 X310_HG" to open the Vivado GUI and build the
> project.
>
> Nick
>
> On Tue, Dec 18, 2018 at 1:33 PM Alexander Olihovik via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> Will running "make X310_HG" generate a .xpr file that I can open with
>> Vivado? I have a .xpr for the E310 from a previous effort so I think it can
>> be done, but I wasn't the originator of this file.
>> I was following this guide:
>> http://files.ettus.com/manual/md_usrp3_build_instructions.html
>>
>> Best,
>> Alex
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

-- 




*Alex OlihovikUniversity of Virginia 2013BS Electrical EngineeringBS
Computer engineeringano...@virginia.edu *
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 Overflows

[Marcus D. Leech via USRP-users]

On 12/19/2018 02:29 PM, Devin Kelly wrote:
I'm using 500 kHz sampling rate.  Wouldn't a lower rate effect my ToF 
accuracy?  My understanding is that with 500 kHz sample rate my best 
ToF accuracy would be 2 us.  My next question is why is the ToF 
shifting by less than 2 us (1/500e3)?  My master clock is 16MHz so 
maybe the ToF shifts by multiples of 1/16e9?


Devin
For a 500ksps sample rate, I wouldn't expect there to be any overruns, 
unless your flow-graph is quite complicated.


Sample streams carry timestamps, so you can look at the timestamps when 
an overrun occurs and compute how many samples were

  lost.





On Wed, Dec 19, 2018 at 2:01 PM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 12/19/2018 01:56 PM, Devin Kelly via USRP-users wrote:
> Hello,
>
> I have an X310 transmitting packets to an E310, the E310 can
> successfully demodulate the packet and estimate the time of flight.
> I'm sending one packet per second for about half an hour and the
ToF
> estimate is very consistent, except for when I have an overflow
on the
> E310.  I get an overflow once every 15-20 minutes or so.
>
> When I get an overflow my ToF estimate increases permanently by a
> small amount, enough to affect my application.  For example, I
might
> get 500 packets in a row with a ToF of 100 us each, then I get an
> overflow and all my remaining packets have a ToF of 101.6 us. 
All the

> USRPs are wired together so my channel isn't changing.  I tried to
> figure out if I could compensate for the difference but I couldn't
> figure it out.  I also tried to reset the PPS on the E310, which
> didn't work.
>
> I know it's on the receive side because I have multiple
receivers and
> I can match each overflow to each ToF change. On the E310 I'm using
> UHD 3.9.2.  Can anyone help me figure this out?
>
> Also, is there a newer image I should be using for the E310?  Or, a
> newer UHD?  It doesn't look like the E310 is supported much
anymore,
> or is there something I'm not seeing?
>
> Thanks,
> Devin
>
What sample rate are you using on the E310?  Can you operate with a
lower rate?



___
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] Faster way to send asynchronous data to RFNoC block

[Brian Padalino via USRP-users]

On Wed, Dec 19, 2018 at 12:53 PM J M via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I'm trying to load a RAM inside an RFNoC block, and doing this via
> register writes takes about a minute and half.
>
> So, looking for a quicker way to load up the data from the RAM, thought
> about a second input to the RFNoC block and source it from the file.  In
> this way, the RFNoC block would have two inputs, one which would be source
> from the radio block, and the second from file, but the file would only run
> through once to load the RAM.
>
> Unfortunately, I haven't found any RFNoC examples that have 2 inputs that
> are not tied together (such as the add/sub block).  Does anyone know of a
> good example of doing this through RFNoC, or if it is even possible?  Or is
> there another mechanism for sending a bunch of data across that I'm
> overlooking?
>

Can you describe the life cycle of your block for us a little bit in more
detail?

If you are loading RAM once and only once before starting any streaming,
you could potentially use a register to choose which mode you are in, and
then the incoming stream can be pushed to RAM, then the register is cleared
once you are sure there is nothing more to write into RAM.  Unfortunately,
without knowing more about your life cycle and how you intend to use the
block, I am not sure the above suggestion would actually work.

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

Re: [USRP-users] E310 Overflows

[Devin Kelly via USRP-users]

I'm using 500 kHz sampling rate.  Wouldn't a lower rate effect my ToF
accuracy?  My understanding is that with 500 kHz sample rate my best ToF
accuracy would be 2 us.  My next question is why is the ToF shifting by
less than 2 us (1/500e3)?  My master clock is 16MHz so maybe the ToF shifts
by multiples of 1/16e9?

Devin


On Wed, Dec 19, 2018 at 2:01 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 12/19/2018 01:56 PM, Devin Kelly via USRP-users wrote:
> > Hello,
> >
> > I have an X310 transmitting packets to an E310, the E310 can
> > successfully demodulate the packet and estimate the time of flight.
> > I'm sending one packet per second for about half an hour and the ToF
> > estimate is very consistent, except for when I have an overflow on the
> > E310.  I get an overflow once every 15-20 minutes or so.
> >
> > When I get an overflow my ToF estimate increases permanently by a
> > small amount, enough to affect my application.  For example, I might
> > get 500 packets in a row with a ToF of 100 us each, then I get an
> > overflow and all my remaining packets have a ToF of 101.6 us.  All the
> > USRPs are wired together so my channel isn't changing.  I tried to
> > figure out if I could compensate for the difference but I couldn't
> > figure it out.  I also tried to reset the PPS on the E310, which
> > didn't work.
> >
> > I know it's on the receive side because I have multiple receivers and
> > I can match each overflow to each ToF change. On the E310 I'm using
> > UHD 3.9.2.  Can anyone help me figure this out?
> >
> > Also, is there a newer image I should be using for the E310?  Or, a
> > newer UHD?  It doesn't look like the E310 is supported much anymore,
> > or is there something I'm not seeing?
> >
> > Thanks,
> > Devin
> >
> What sample rate are you using on the E310?  Can you operate with a
> lower rate?
>
>
>
> ___
> 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] E310 Overflows

[Marcus D. Leech via USRP-users]

On 12/19/2018 01:56 PM, Devin Kelly via USRP-users wrote:

Hello,

I have an X310 transmitting packets to an E310, the E310 can 
successfully demodulate the packet and estimate the time of flight.  
I'm sending one packet per second for about half an hour and the ToF 
estimate is very consistent, except for when I have an overflow on the 
E310.  I get an overflow once every 15-20 minutes or so.


When I get an overflow my ToF estimate increases permanently by a 
small amount, enough to affect my application.  For example, I might 
get 500 packets in a row with a ToF of 100 us each, then I get an 
overflow and all my remaining packets have a ToF of 101.6 us.  All the 
USRPs are wired together so my channel isn't changing.  I tried to 
figure out if I could compensate for the difference but I couldn't 
figure it out.  I also tried to reset the PPS on the E310, which 
didn't work.


I know it's on the receive side because I have multiple receivers and 
I can match each overflow to each ToF change. On the E310 I'm using 
UHD 3.9.2.  Can anyone help me figure this out?


Also, is there a newer image I should be using for the E310?  Or, a 
newer UHD?  It doesn't look like the E310 is supported much anymore, 
or is there something I'm not seeing?


Thanks,
Devin

What sample rate are you using on the E310?  Can you operate with a 
lower rate?




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

[USRP-users] E310 Overflows

[Devin Kelly via USRP-users]

Hello,

I have an X310 transmitting packets to an E310, the E310 can successfully
demodulate the packet and estimate the time of flight.  I'm sending one
packet per second for about half an hour and the ToF estimate is very
consistent, except for when I have an overflow on the E310.  I get an
overflow once every 15-20 minutes or so.

When I get an overflow my ToF estimate increases permanently by a small
amount, enough to affect my application.  For example, I might get 500
packets in a row with a ToF of 100 us each, then I get an overflow and all
my remaining packets have a ToF of 101.6 us.  All the USRPs are wired
together so my channel isn't changing.  I tried to figure out if I could
compensate for the difference but I couldn't figure it out.  I also tried
to reset the PPS on the E310, which didn't work.

I know it's on the receive side because I have multiple receivers and I can
match each overflow to each ToF change.  On the E310 I'm using UHD 3.9.2.
Can anyone help me figure this out?

Also, is there a newer image I should be using for the E310?  Or, a newer
UHD?  It doesn't look like the E310 is supported much anymore, or is there
something I'm not seeing?

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

[USRP-users] Repost: RFNOC GPIO throws bad allocation error

[Chatterjee, Pratik via USRP-users]

Hi all,


Re-posting this question 
(https://www.mail-archive.com/usrp-users@lists.ettus.com/msg06892.html). The 
use of set_gpio_attr with rfnoc radio_ctrl_impl throws bad allocation error. I 
am stuck with this problem for some time and its important for the project I am 
working on. Can anyone please point out if I am doing something wrong while 
calling the gpio functionality or is this an issue Ettus is still looking at ? 
( https://www.mail-archive.com/usrp-users@lists.ettus.com/msg06579.html)



  1.  uhd::device3::sptr usrp = uhd::device3::make(args);
  2.  uhd::rfnoc::radio_ctrl::sptr radio_ctrl = 
usrp->get_block_ctrl(radio_ctrl_id);
  3.  radio_ctrl->set_gpio_attr("FP0", "CTRL", ATR_CONTROL, ATR_MASK);

Thanks,
Pratik


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

Re: [USRP-users] N310 3.12.0.0 sd image issue

[Ali Dormiani via USRP-users]

Hello,

I have run into this problem regularly. This problem seems to be linked
with the SD card and is not a software issue.

Try the following:

1. Cleanly format the SD card (write all 0's to it) and then use UHD to
image it. I prefer to use CCleaner and windows disk manager. It should take
an hour or so depending on how many stubborn sectors your card has.

2. Use a different SD card. NAND flash has a finite write endurance and
micro SD cards can die from too many image flashes. I managed to burn/kill
four 16 Gb micro SD cards over the summer. You can buy a pack of 10 for
around $40 on Amazon/Newegg.



On Wed, Dec 19, 2018 at 6:39 AM Tillson, Bob (US) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have a third party app compiled and linked with 3.12.0.0.
>
>
>
> I have burned the SD card image for the N310 from here
> http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.12.0.0/
>
> to the SD card.
>
>
>
> All partitions look proper from another linux machine.
>
>
>
> When I boot the N310 with that sd card I get the following error info on
> the console:
>
>
>
> *U-Boot SPL 2017.09 (Jun 14 2018 - 22:07:24)*
>
> *mmc boot*
>
> *Trying to boot from MMC1*
>
> *reading u-boot.img*
>
> *reading u-boot.img*
>
>
>
>
>
> *U-Boot 2017.09 (Jun 14 2018 - 22:07:24 +)*
>
>
>
> *Model: NI Ettus Research Project Sulfur/Phosphorus SDR*
>
> *DRAM:  ECC disabled 1 GiB*
>
> *MMC:   sdhci@e010: 0*
>
>  Warning - bad CRC, using default environment*
>
>
>
> *In:serial@e000*
>
> *Out:   serial@e000*
>
> *Err:   serial@e000*
>
> *Model: NI Ettus Research Project Sulfur/Phosphorus SDR*
>
> *NI Ettus Research Project Sulfur SDR Rev G s/n 316A5C9 *
>
> *Slot 0: Magnesium XCVR Rev D s/n: 3159C37*
>
> *Slot 1: Magnesium XCVR Rev D s/n: 3159C0F*
>
> *Automatic boot in 0s...*
>
> *Enter 'noautoboot' to enter prompt without timeout*
>
> *Copying MCU FW from SD to RAM...*
>
> *** File not found lib/firmware/ni/ec-sulfur-rev7.RW.bin ***
>
> *Copying FIT from SD to RAM...*
>
> *5792964 bytes read in 388 ms (14.2 MiB/s)*
>
> *## Loading kernel from FIT Image at 0200 ...*
>
> *Could not find configuration node*
>
> *ERROR: can't get kernel image!*
>
> *## Error: "distro_bootcmd" not defined*
>
> *ni-sulfur-uboot> *
>
>
>
> Any thoughts as to what is going wrong?
>
>
>
> Unfortunately with the app being third party and from an external source,
> I don’t have much recourse…
> ___
> 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] Faster way to send asynchronous data to RFNoC block

[J M via USRP-users]

Hi,

I'm trying to load a RAM inside an RFNoC block, and doing this via register
writes takes about a minute and half.

So, looking for a quicker way to load up the data from the RAM, thought
about a second input to the RFNoC block and source it from the file.  In
this way, the RFNoC block would have two inputs, one which would be source
from the radio block, and the second from file, but the file would only run
through once to load the RAM.

Unfortunately, I haven't found any RFNoC examples that have 2 inputs that
are not tied together (such as the add/sub block).  Does anyone know of a
good example of doing this through RFNoC, or if it is even possible?  Or is
there another mechanism for sending a bunch of data across that I'm
overlooking?

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

[USRP-users] N310 3.12.0.0 sd image issue

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

I have a third party app compiled and linked with 3.12.0.0.

I have burned the SD card image for the N310 from here 
http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.12.0.0/
to the SD card.

All partitions look proper from another linux machine.

When I boot the N310 with that sd card I get the following error info on the 
console:

U-Boot SPL 2017.09 (Jun 14 2018 - 22:07:24)
mmc boot
Trying to boot from MMC1
reading u-boot.img
reading u-boot.img


U-Boot 2017.09 (Jun 14 2018 - 22:07:24 +)

Model: NI Ettus Research Project Sulfur/Phosphorus SDR
DRAM:  ECC disabled 1 GiB
MMC:   sdhci@e010: 0
*** Warning - bad CRC, using default environment

In:serial@e000
Out:   serial@e000
Err:   serial@e000
Model: NI Ettus Research Project Sulfur/Phosphorus SDR
NI Ettus Research Project Sulfur SDR Rev G s/n 316A5C9
Slot 0: Magnesium XCVR Rev D s/n: 3159C37
Slot 1: Magnesium XCVR Rev D s/n: 3159C0F
Automatic boot in 0s...
Enter 'noautoboot' to enter prompt without timeout
Copying MCU FW from SD to RAM...
** File not found lib/firmware/ni/ec-sulfur-rev7.RW.bin **
Copying FIT from SD to RAM...
5792964 bytes read in 388 ms (14.2 MiB/s)
## Loading kernel from FIT Image at 0200 ...
Could not find configuration node
ERROR: can't get kernel image!
## Error: "distro_bootcmd" not defined
ni-sulfur-uboot>

Any thoughts as to what is going wrong?

Unfortunately with the app being third party and from an external source, I 
don't have much recourse...
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] mpm build for N310

[Jason Matusiak via USRP-users]

I think I need to rebuild mpm since I rebuilt UHD for the embedded N310.
 
I tried to rebuild it on the host with cross-compile sourced, but I get this 
error that keeps make from working:
 
CMake Warning at 
/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindBoost.cmake:1643
 (message):
 No header defined for python3; skipping header check
Call Stack (most recent call first):
 CMakeLists.txt:93 (FIND_PACKAGE)
 My command was: cmake 
-DCMAKE_TOOLCHAIN_FILE=/opt/gnuradio/N310/src/uhd/host/cmake/Toolchains/oe-sdk_cross.cmake
 -DCMAKE_INSTALL_PREFIX=/usr ..
 Has anyone else gotten this to build?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Synthesize custom RFNoC block error

[Anabel Almodovar via USRP-users]

Hello,

I am trying to synthesize a custom IP core generated by HLS to generate a
RFNoC custom block, but when I run ./uhd_image_builder.py I get the
following error:



































*--Using the following blocks to generate image:* myFir*
despFreq* ddc* fftAdding CE instantiation file for
'X310_RFNOC_HG'changing temporarily working directory to
/home/usrp_2018/rfnoc/src/uhd-fpga/usrp3/tools/scripts/../../top/x300Setting
up a 64-bit FPGA build environment for the USRP-X3x0...- Vivado: Found
(/opt/Xilinx/Vivado/2017.4/bin)Environment successfully initialized.make -f
Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH=kintex7
PART_ID=xc7k410t/ffg900/-2 BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1
RFNOC=1 X310=1  TOP_MODULE=x300 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1
SFP0_1GBE=1 SFP1_10GBE=1  RFNOC=1 X310=1 "make[1]: se entra en el
directorio '/home/usrp_2018/rfnoc/src/uhd-fpga/usrp3/top/x300'BUILDER:
Checking tools...* GNU bash, versión 4.3.48(1)-release
(x86_64-pc-linux-gnu)* Python 2.7.12* Vivado v2017.4 (64-bit)Using parser
configuration from:
/home/usrp_2018/rfnoc/src/uhd-fpga/usrp3/top/x300/dev_config.json[00:00:00]
Executing command: vivado -mode batch -source
/home/usrp_2018/rfnoc/src/uhd-fpga/usrp3/top/x300/build_x300.tcl -log
build.log -journal x300.jouCRITICAL WARNING: [filemgmt 20-1440] File
'/home/usrp_2018/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit/user_design/rtl/clocking/mig_7series_v4_0_tempmon.v'
already exists in the project as a part of sub-design file
'/home/usrp_2018/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit.xci'.
Explicitly adding the file outside the scope of the sub-design can lead to
unintended behaviors and is not recommended.ERROR: [Common 17-107] Cannot
change read-only property 'generate_synth_checkpoint'.[00:00:41] Current
task: Initialization +++ Current Phase: Starting[00:00:41] Current task:
Initialization +++ Current Phase: Finished[00:00:41] Process terminated.
Status:
FailureWarnings:
0Critical Warnings:  1Errors: 1Makefile.x300.inc:111: fallo en
las instrucciones para el objetivo 'bin'make[1]: *** [bin] Error 1make[1]:
se sale del directorio
'/home/usrp_2018/rfnoc/src/uhd-fpga/usrp3/top/x300'Makefile:119: fallo en
las instrucciones para el objetivo 'X310_RFNOC_HG'make: *** [X310_RFNOC_HG]
Error 2*

If I synthesize an existing IP Core, it runs fine. I am using a X310 board
and 2017.4 vivado version.
Does anyone know what it means and how can I solve the problem?

Regards,

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

Re: [USRP-users] Phase Offset problem when center frequency is changed dynamically

[Arun kumar Verma via USRP-users]

Well even if my loop is executing more than 16 times if I use 
clear_command_time it should clear the item  from FIFO. is this  correct ? or 
any other command for clearing the timed-commands queue.

    uhd::time_spec_t temp = usrp_sourceDOA1->get_time_now();
    usrp_sourceDOA1->set_command_time(temp + uhd::time_spec_t(0.01));
    usrp_source1->set_rx_freq(tune_req,0);
    usrp_source1->set_rx_freq(tune_req,1);
    SleeperThread::msleep(100);
    usrp_sourceDOA1->clear_command_time();
Arun

  From: Marcus D. Leech 
 To: Arun kumar Verma ; "usrp-users@lists.ettus.com" 
 
 Sent: Wednesday, 19 December 2018 1:00 AM
 Subject: Re: [USRP-users] Phase Offset problem when center frequency is 
changed dynamically
   
 On 12/18/2018 05:07 AM, Arun kumar Verma wrote:
  
  Dear Marcus 
  I  found the real problem and problem is that when i use set_command_time in 
loop then only problem exist, if do not use this my loop is getting executed 
properly. But for phase synchronization i have to use set_command_time  Any 
suggestion? 
   

  Arun Verma 

 How rapidly is that loop executing?  The timed-command queue is only 16 items 
deep, and you're scheduling at 0.01sec intervals.
 
 
 
  
From: Arun kumar Verma via USRP-users 
 To: Marcus D. Leech ; "usrp-users@lists.ettus.com" 
 
 Sent: Tuesday, 18 December 2018 2:16 PM
 Subject: Re: [USRP-users] Phase Offset problem when center frequency is 
changed dynamically
  
Dear Marcus 
  The problem is solved by setting RF policy manual for RF and DSP both and 
passing uhd::tune_request_t  object as parameter to set_center_freq function, 
but now i getting one more issues that after 35-40 iteration my application is  
getting assertion because of  "EnvironmentError: IOError: Block ctrl 
(CE_00_Port_30) no response packet - AssertionError: bool(buff)" and after that 
I have to start X310 again then only it responds.
  
  My setup is X310 with single TwinRX module and I want to measure the phase 
difference from 10-6000MHz and put into look-up table. I am using B205-mini as 
transmitter and it is connected with the power divider to X310 input. I am  
working on phase interferometer direction finding with 5 element circular array 
antennae connected to 5 to 2 Antenna Switch matrix which is connected to single 
 TwinRX. 
  
  I am not sure how  set_center_freq command is implemented internally for 
TwinRX,  but i expect that when i set this command, only LOs should be tuned 
for desired frequencies plus some filter selection of that band. I expect that 
settling time for synthesizer would be around maximum of 300uS  and for some 
other stuff like filter selection , i think in  500uS I should be able to set 
everything. At present I have to use set_command_time so that my channels are 
synchronized. Can you suggest the fastest way to implementing frequency sweep 
for two channels as i need scan rate around 40GHz. 
  Regards, Arun Verma
  
  From: Marcus D. Leech via USRP-users 
 To: usrp-users@lists.ettus.com 
 Sent: Monday, 17 December 2018 10:36 PM
 Subject: Re: [USRP-users] Phase Offset problem when center frequency is 
changed dynamically
  
On 12/15/2018 08:02 AM, Arun kumar Verma via USRP-users wrote:
  
  Dear Users 
  I am facing problem of phase offset when i change center  frequency 
dynamically for TwinRX with X310 setup. Here is my C++ code, 
  
  Please advise 
     
usrp_source1->set_rx_lo_source("internal",uhd::usrp::multi_usrp::ALL_LOS,0);
    
usrp_source1->set_rx_lo_source("companion",uhd::usrp::multi_usrp::ALL_LOS,1); 
          
usrp_sourceDOA1->set_command_time(usrp_sourceDOA1->get_time_now() + 
uhd::time_spec_t(0.01));
     usrp_sourceDOA1->set_center_freq(m_CenterFrequency,0);
     usrp_sourceDOA1->set_center_freq(m_CenterFrequency,1);
     usrp_sourceDOA1->clear_command_time(); 
  I feel set_command_time is not working properly. When i  start the X310 my 
phase difference is almost zero but as i change my frequency  pjhase difference 
is random in nature. 
  Regards, Arun Verma 
  
  COuld you explain your setup a bit more here.
 
 I now see that you have both usrp_source1 and usrp_sourceDOA1, but I think you 
said that you have a single X310, so I'm confused about
   why you apparently have two USRP sources here.
 
 
   ___
 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