Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Marcus D. Leech via USRP-users]

On 03/09/2018 01:22 PM, Nick Foster wrote:
One thing that struck me: I don't think you should have to disable the 
streamer to switch between cal and radio channels. Just for 
experiment's sake, try leaving both channels active in the streamer. 
You can pull samples from both channels in your recv() command, and 
just use the channel you're interested in. Does doing this affect the 
result?


Nick
One thing that I recall--the E3XX has two separate TOD clocks, which 
MUST be synchronized to get synchronized streaming, even though this is the

  same physical radio.

Do a set_time_unknown_pps() on both channels, and then start streaming 
at some future point--does that help?





On Fri, Mar 9, 2018 at 10:13 AM Samuel Prager > wrote:


Hey Nick,

No prob blew at all. The flag /“no_reload_fpga”/ seems to work for
that. The bigger problem is that each time the fpga image is
loaded on the e3xx, the relative path delays between the RXA and
RXB channels changes randomly as seen by the sample group jumps in
the image I originally attached. The random LO phase is measured
and removed, so there is something else happening in this strange
case.

If anyone has any ideas as to what could be causing this please
help! The phase stability of the E312 is amazing within the same
fpga image cycle but these relatively large jumps after reload/
power cycle are a deal breaker for some applications!

Thanks

Sam

On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users
>,
wrote:

Sam,

Sorry I haven't gotten back -- it sounds like you're doing
everything right. The usual quick fixes probably don't apply
here. I haven't had time to look more in depth into it, or to try
to replicate it on my own hardware.

Marcus is right -- the E3xx uses an idle image in order to reduce
power consumption when the radio is inactive. I'm not sure if
there's a flag that will tell UHD not to load the idle image.

Nick

On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users
>
wrote:

On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:

Still looking for more info on this problem.

I have the exact same RfNoC block/software program running
on an X300 and see no such jumps or otherwise unexpected
behavior.

I have attempted to isolate this issue on the E312 by
creating the device3 with the */“no_reload_fpga”/* flag.
(Appropriate image is loaded before hand with the
uhd_usrp_image_loader. Running my program the first time
works as expected, but if I kill the program and restart, I
get this error:

/“AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE)
> 0 in virtual void e300_fifo_mb::release()"/

The last few lines in the Uhd log file are:


/e300_impl.cpp:639,1,E300,[E300] Setting up dest map for
host ep 0 to be stream 0

device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell
Control for port #0 (SID; 00:00>02:10)
device3_impl.cpp:139,0,DEVICE3, OK
davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block
with ID 12AD1000.
e300_impl.cpp:639,1,E300, [E300] Setting up dest map for
host ep 1 to be stream 1

device3_impl.cpp:160,0,DEVICE3, Setting up NoC Shell port
for #1 (SID: 00:01>02:11)/



Shouldn’t the E312 be able to operate without needing to
reload the FPGA image each time? Has this been tested? I
would really appreciate any hints or pointers into why this
is happening.

Thank you,

Sam


The E3xx run an "idle" image when the device is not being
used.  I cannot remember the reason for that, TBH.


___
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 

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwICAg=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=opIuWAKmywF059tAs2i3Pg=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU=

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Samuel Prager via USRP-users]

Hi Nick,

I can try this, but the reason I disable one or the other streamer is so that I 
can sample at the full 50MHz. Running both streamers cuts the sample rate in 
half and I am only using the cal channel to measure/correct the random LO phase 
offset.

In this switching mode, the data always comes from radio block 1, but the 
AD9361 routes it to either RXA or RXB at full rate depending on the active 
streamer.

I also switch back and forth between the channels thousands of times on a 
single power cycle without an issue.

Even if I only receive on a single channel (RXA) and match filter with a 
reference waveform file, I am still seeing the same behavior: tight groupings 
in measured phase slope delay but with random hops in group mean whenever the 
image is reloaded.

Sam

On Mar 9, 2018, 10:22 AM -0800, Nick Foster , wrote:
> One thing that struck me: I don't think you should have to disable the 
> streamer to switch between cal and radio channels. Just for experiment's 
> sake, try leaving both channels active in the streamer. You can pull samples 
> from both channels in your recv() command, and just use the channel you're 
> interested in. Does doing this affect the result?
>
> Nick
>
> > On Fri, Mar 9, 2018 at 10:13 AM Samuel Prager  wrote:
> > > Hey Nick,
> > >
> > > No prob blew at all. The flag “no_reload_fpga” seems to work for that. 
> > > The bigger problem is that each time the fpga image is loaded on the 
> > > e3xx, the relative path delays between the RXA and RXB channels changes 
> > > randomly as seen by the sample group jumps in the image I originally 
> > > attached. The random LO phase is measured and removed, so there is 
> > > something else happening in this strange case.
> > >
> > > If anyone has any ideas as to what could be causing this please help! The 
> > > phase stability of the E312 is amazing within the same fpga image cycle 
> > > but these relatively large jumps after reload/ power cycle are a deal 
> > > breaker for some applications!
> > >
> > > Thanks
> > >
> > > Sam
> > >
> > > On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users 
> > > , wrote:
> > > > Sam,
> > > >
> > > > Sorry I haven't gotten back -- it sounds like you're doing everything 
> > > > right. The usual quick fixes probably don't apply here. I haven't had 
> > > > time to look more in depth into it, or to try to replicate it on my own 
> > > > hardware.
> > > >
> > > > Marcus is right -- the E3xx uses an idle image in order to reduce power 
> > > > consumption when the radio is inactive. I'm not sure if there's a flag 
> > > > that will tell UHD not to load the idle image.
> > > >
> > > > Nick
> > > >
> > > > > On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users 
> > > > >  wrote:
> > > > > > On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:
> > > > > > > Still looking for more info on this problem.
> > > > > > >
> > > > > > > I have the exact same RfNoC block/software program running on an 
> > > > > > > X300 and see no such jumps or otherwise unexpected behavior.
> > > > > > >
> > > > > > > I have attempted to isolate this issue on the E312 by creating 
> > > > > > > the device3 with the “no_reload_fpga” flag. (Appropriate image is 
> > > > > > > loaded before hand with the uhd_usrp_image_loader. Running my 
> > > > > > > program the first time works as expected, but if I kill the 
> > > > > > > program and restart, I get this error:
> > > > > > >
> > > > > > > “AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 
> > > > > > > in virtual void e300_fifo_mb::release()"
> > > > > > >
> > > > > > > The last few lines in the Uhd log file are:
> > > > > > >
> > > > > > >
> > > > > > > e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 
> > > > > > > to be stream 0
> > > > > > >
> > > > > > > device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for 
> > > > > > > port #0 (SID; 00:00>02:10)
> > > > > > > device3_impl.cpp:139,0,DEVICE3, OK
> > > > > > > davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID 
> > > > > > > 12AD1000.
> > > > > > > e300_impl.cpp:639,1,E300, [E300] Setting up dest map for host ep 
> > > > > > > 1 to be stream 1
> > > > > > >
> > > > > > > device3_impl.cpp:160,0,DEVICE3, Setting up NoC Shell port for #1 
> > > > > > > (SID: 00:01>02:11)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Shouldn’t the E312 be able to operate without needing to reload 
> > > > > > > the FPGA image each time? Has this been tested? I would really 
> > > > > > > appreciate any hints or pointers into why this is happening.
> > > > > > >
> > > > > > > Thank you,
> > > > > > >
> > > > > > > Sam
> > > > > > >
> > > > > > The E3xx run an "idle" image when the device is not being used.  I 
> > > > > > cannot remember the reason for that, TBH.
> > > > > >
> > > > > >
> > > > > > ___

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Nick Foster via USRP-users]

One thing that struck me: I don't think you should have to disable the
streamer to switch between cal and radio channels. Just for experiment's
sake, try leaving both channels active in the streamer. You can pull
samples from both channels in your recv() command, and just use the channel
you're interested in. Does doing this affect the result?

Nick

On Fri, Mar 9, 2018 at 10:13 AM Samuel Prager  wrote:

> Hey Nick,
>
> No prob blew at all. The flag *“no_reload_fpga”* seems to work for that.
> The bigger problem is that each time the fpga image is loaded on the e3xx,
> the relative path delays between the RXA and RXB channels changes randomly
> as seen by the sample group jumps in the image I originally attached. The
> random LO phase is measured and removed, so there is something else
> happening in this strange case.
>
> If anyone has any ideas as to what could be causing this please help! The
> phase stability of the E312 is amazing within the same fpga image cycle but
> these relatively large jumps after reload/ power cycle are a deal breaker
> for some applications!
>
> Thanks
>
> Sam
>
> On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users <
> usrp-users@lists.ettus.com>, wrote:
>
> Sam,
>
> Sorry I haven't gotten back -- it sounds like you're doing everything
> right. The usual quick fixes probably don't apply here. I haven't had time
> to look more in depth into it, or to try to replicate it on my own hardware.
>
> Marcus is right -- the E3xx uses an idle image in order to reduce power
> consumption when the radio is inactive. I'm not sure if there's a flag that
> will tell UHD not to load the idle image.
>
> Nick
>
> On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:
>>
>> Still looking for more info on this problem.
>>
>> I have the exact same RfNoC block/software program running on an X300 and
>> see no such jumps or otherwise unexpected behavior.
>>
>> I have attempted to isolate this issue on the E312 by creating the
>> device3 with the *“no_reload_fpga”* flag. (Appropriate image is loaded
>> before hand with the uhd_usrp_image_loader. Running my program the first
>> time works as expected, but if I kill the program and restart, I get this
>> error:
>>
>> *“AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 in
>> virtual void e300_fifo_mb::release()"*
>>
>> The last few lines in the Uhd log file are:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 to be
>> stream 0 device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for
>> port #0 (SID; 00:00>02:10) device3_impl.cpp:139,0,DEVICE3, OK
>> davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID
>> 12AD1000. e300_impl.cpp:639,1,E300, [E300] Setting up dest map for
>> host ep 1 to be stream 1 device3_impl.cpp:160,0,DEVICE3, Setting up NoC
>> Shell port for #1 (SID: 00:01>02:11)*
>>
>>
>>
>> Shouldn’t the E312 be able to operate without needing to reload the FPGA
>> image each time? Has this been tested? I would really appreciate any hints
>> or pointers into why this is happening.
>>
>> Thank you,
>>
>> Sam
>>
>> The E3xx run an "idle" image when the device is not being used.  I cannot
>> remember the reason for that, TBH.
>>
>>
>> ___
>> 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
>
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwICAg=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=opIuWAKmywF059tAs2i3Pg=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU=
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Samuel Prager via USRP-users]

Hey Nick,

No prob blew at all. The flag “no_reload_fpga” seems to work for that. The 
bigger problem is that each time the fpga image is loaded on the e3xx, the 
relative path delays between the RXA and RXB channels changes randomly as seen 
by the sample group jumps in the image I originally attached. The random LO 
phase is measured and removed, so there is something else happening in this 
strange case.

If anyone has any ideas as to what could be causing this please help! The phase 
stability of the E312 is amazing within the same fpga image cycle but these 
relatively large jumps after reload/ power cycle are a deal breaker for some 
applications!

Thanks

Sam

On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users 
, wrote:
> Sam,
>
> Sorry I haven't gotten back -- it sounds like you're doing everything right. 
> The usual quick fixes probably don't apply here. I haven't had time to look 
> more in depth into it, or to try to replicate it on my own hardware.
>
> Marcus is right -- the E3xx uses an idle image in order to reduce power 
> consumption when the radio is inactive. I'm not sure if there's a flag that 
> will tell UHD not to load the idle image.
>
> Nick
>
> > On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users 
> >  wrote:
> > > On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:
> > > > Still looking for more info on this problem.
> > > >
> > > > I have the exact same RfNoC block/software program running on an X300 
> > > > and see no such jumps or otherwise unexpected behavior.
> > > >
> > > > I have attempted to isolate this issue on the E312 by creating the 
> > > > device3 with the “no_reload_fpga” flag. (Appropriate image is loaded 
> > > > before hand with the uhd_usrp_image_loader. Running my program the 
> > > > first time works as expected, but if I kill the program and restart, I 
> > > > get this error:
> > > >
> > > > “AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 in 
> > > > virtual void e300_fifo_mb::release()"
> > > >
> > > > The last few lines in the Uhd log file are:
> > > >
> > > >
> > > > e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 to be 
> > > > stream 0
> > > >
> > > > device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for port 
> > > > #0 (SID; 00:00>02:10)
> > > > device3_impl.cpp:139,0,DEVICE3, OK
> > > > davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID 
> > > > 12AD1000.
> > > > e300_impl.cpp:639,1,E300, [E300] Setting up dest map for host ep 1 to 
> > > > be stream 1
> > > >
> > > > device3_impl.cpp:160,0,DEVICE3, Setting up NoC Shell port for #1 (SID: 
> > > > 00:01>02:11)
> > > >
> > > >
> > > >
> > > > Shouldn’t the E312 be able to operate without needing to reload the 
> > > > FPGA image each time? Has this been tested? I would really appreciate 
> > > > any hints or pointers into why this is happening.
> > > >
> > > > Thank you,
> > > >
> > > > Sam
> > > >
> > > The E3xx run an "idle" image when the device is not being used.  I cannot 
> > > remember the reason for that, TBH.
> > >
> > >
> > > ___
> > > 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
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwICAg=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=opIuWAKmywF059tAs2i3Pg=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU=
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Nick Foster via USRP-users]

Sam,

Sorry I haven't gotten back -- it sounds like you're doing everything
right. The usual quick fixes probably don't apply here. I haven't had time
to look more in depth into it, or to try to replicate it on my own hardware.

Marcus is right -- the E3xx uses an idle image in order to reduce power
consumption when the radio is inactive. I'm not sure if there's a flag that
will tell UHD not to load the idle image.

Nick

On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:
>
> Still looking for more info on this problem.
>
> I have the exact same RfNoC block/software program running on an X300 and
> see no such jumps or otherwise unexpected behavior.
>
> I have attempted to isolate this issue on the E312 by creating the device3
> with the *“no_reload_fpga”* flag. (Appropriate image is loaded before
> hand with the uhd_usrp_image_loader. Running my program the first time
> works as expected, but if I kill the program and restart, I get this error:
>
> *“AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 in
> virtual void e300_fifo_mb::release()"*
>
> The last few lines in the Uhd log file are:
>
>
>
>
>
>
>
>
>
> *e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 to be
> stream 0 device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for
> port #0 (SID; 00:00>02:10) device3_impl.cpp:139,0,DEVICE3, OK
> davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID
> 12AD1000. e300_impl.cpp:639,1,E300, [E300] Setting up dest map for
> host ep 1 to be stream 1 device3_impl.cpp:160,0,DEVICE3, Setting up NoC
> Shell port for #1 (SID: 00:01>02:11)*
>
>
>
> Shouldn’t the E312 be able to operate without needing to reload the FPGA
> image each time? Has this been tested? I would really appreciate any hints
> or pointers into why this is happening.
>
> Thank you,
>
> Sam
>
> The E3xx run an "idle" image when the device is not being used.  I cannot
> remember the reason for that, TBH.
>
>
> ___
> 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] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Marcus D. Leech via USRP-users]

On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:

Still looking for more info on this problem.

I have the exact same RfNoC block/software program running on an X300 
and see no such jumps or otherwise unexpected behavior.


I have attempted to isolate this issue on the E312 by creating the 
device3 with the */“no_reload_fpga”/* flag. (Appropriate image is 
loaded before hand with the uhd_usrp_image_loader. Running my program 
the first time works as expected, but if I kill the program and 
restart, I get this error:


/“AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 in 
virtual void e300_fifo_mb::release()"/


The last few lines in the Uhd log file are:


/e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 to 
be stream 0


device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for port 
#0 (SID; 00:00>02:10)

device3_impl.cpp:139,0,DEVICE3, OK
davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID 
12AD1000.
e300_impl.cpp:639,1,E300, [E300] Setting up dest map for host ep 1 to 
be stream 1


device3_impl.cpp:160,0,DEVICE3, Setting up NoC Shell port for #1 (SID: 
00:01>02:11)/




Shouldn’t the E312 be able to operate without needing to reload the 
FPGA image each time? Has this been tested? I would really appreciate 
any hints or pointers into why this is happening.


Thank you,

Sam

The E3xx run an "idle" image when the device is not being used.  I 
cannot remember the reason for that, TBH.



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

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Samuel Prager via USRP-users]

Still looking for more info on this problem.

I have the exact same RfNoC block/software program running on an X300 and see 
no such jumps or otherwise unexpected behavior.

I have attempted to isolate this issue on the E312 by creating the device3 with 
the “no_reload_fpga” flag. (Appropriate image is loaded before hand with the 
uhd_usrp_image_loader. Running my program the first time works as expected, but 
if I kill the program and restart, I get this error:

“AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 in virtual void 
e300_fifo_mb::release()"

The last few lines in the Uhd log file are:


e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 to be stream 0

device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for port #0 (SID; 
00:00>02:10)
device3_impl.cpp:139,0,DEVICE3, OK
davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID 
12AD1000.
e300_impl.cpp:639,1,E300, [E300] Setting up dest map for host ep 1 to be stream 
1

device3_impl.cpp:160,0,DEVICE3, Setting up NoC Shell port for #1 (SID: 
00:01>02:11)



Shouldn’t the E312 be able to operate without needing to reload the FPGA image 
each time? Has this been tested? I would really appreciate any hints or 
pointers into why this is happening.

Thank you,

Sam

On Mar 6, 2018, 12:40 PM -0800, Prager, Samuel M (334E) via USRP-users 
<usrp-users@lists.ettus.com>, wrote:
> Hi Nick,
>
> Thanks for the response. I am streaming from one channel at a time. I switch 
> between channels by toggling:
>
>  _radio_ctrl->set_rx_streamer(false, _radio_chan);
>  _radio_ctrl->set_rx_streamer(true, _calib_chan);
>
> And then issue timed RX stream commands:
>
> uhd::time_spec_t timenow = _radio_ctrl->get_time_now();
>        uhd::time_spec_t time_spec = 
> uhd::time_spec_t(seconds_in_future)+timenow;
>         stream_cmd.stream_now = false;
>    stream_cmd.time_spec = time_spec;
> issue_stream_cmd_override(stream_cmd, _radio_chan);
>
> Where issue_stream_cmd_override() is the same as 
> _radio_ctrl->issue_stream_cmd() except that it doesn’t check that the 
> requested channel is active (easiest way I found to quickly switch between 
> RXA and RXB). I also set the MCS register in the aD9361 initialization so 
> that the two channels are phase coherent.
>
> A signal generator upstream from the radio in the FPGA generates the TX pulse 
> on request (with a timestamp to forward) and creates a vita header with the 
> same timestamp used for the RX stream command, so TX and RX begin at the same 
> clock cycle.
>
> Thanks,
>
> Sam
>
> From: Nick Foster [mailto:bistrom...@gmail.com]
> Sent: Tuesday, March 06, 2018 11:57 AM
> To: Prager, Samuel M (334E) <samuel.m.pra...@jpl.nasa.gov>
> Cc: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is 
> reloaded
>
> Could you post your flowgraph or UHD program, or the relevant excerpts? Are 
> the two RX channels being loaded simultaneously? Are you using timed commands 
> to start the RX and TX streams?
> Nick
>
> On Tue, Mar 6, 2018 at 11:52 AM Prager, Samuel M (334E) via USRP-users 
> <usrp-users@lists.ettus.com> wrote:
> > quote_type
> > Hello,
> >
> > We are interested in using the E312 as a phase-sensitive radar sounder and 
> > have run into an interesting issue.
> >
> > We are measuring (relative) cable length by estimating linear phase slope 
> > from a 10MHz chirp pulse and are using the following test setup (attached):
> >
> > We have set the appropriate AD9361 registers to keep the VCO/PLL dividers 
> > on so that RXA (data) and RXB (calibration) are phase coherent. We perform 
> > pulse averaging on each channel and match filter with the cal channel pulse 
> > (shorter cable).
> >
> > We have noticed that the phase measurements remain stable within <1 cm 99% 
> > confidence interval for successive trials with multiple re-tunings of the 
> > LO over long periods of time. However, we have found that if the FPGA bit 
> > file is unloaded (put in idle mode) and then reloaded (either through 
> > power-cycle or termination of UHD-based application), the measured phase 
> > slope jumps randomly.
> >
> > We’re really scratching our heads over this behavior… multiple trials on a 
> > given ‘cycle’ remain stable around a mean value, but that value jumps 
> > around from cycle to cycle in a seemingly random way.
> >
> > I have attached plots for two tests - the vertical black dotted lines are 
> > placed to show when the E312 FPGA image was cycled. Each data point is 
> > taken from a separate LO tuning (ie. 

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Prager, Samuel M (334E) via USRP-users]

Hi Nick,

Thanks for the response. I am streaming from one channel at a time. I switch 
between channels by toggling:

 _radio_ctrl->set_rx_streamer(false, _radio_chan);
 _radio_ctrl->set_rx_streamer(true, _calib_chan);

And then issue timed RX stream commands:

uhd::time_spec_t timenow = _radio_ctrl->get_time_now();
   uhd::time_spec_t time_spec = 
uhd::time_spec_t(seconds_in_future)+timenow;
stream_cmd.stream_now = false;
   stream_cmd.time_spec = time_spec;
issue_stream_cmd_override(stream_cmd, _radio_chan);

Where issue_stream_cmd_override() is the same as 
_radio_ctrl->issue_stream_cmd() except that it doesn’t check that the requested 
channel is active (easiest way I found to quickly switch between RXA and RXB). 
I also set the MCS register in the aD9361 initialization so that the two 
channels are phase coherent.

A signal generator upstream from the radio in the FPGA generates the TX pulse 
on request (with a timestamp to forward) and creates a vita header with the 
same timestamp used for the RX stream command, so TX and RX begin at the same 
clock cycle.

Thanks,

Sam

From: Nick Foster [mailto:bistrom...@gmail.com]
Sent: Tuesday, March 06, 2018 11:57 AM
To: Prager, Samuel M (334E) <samuel.m.pra...@jpl.nasa.gov>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is 
reloaded

Could you post your flowgraph or UHD program, or the relevant excerpts? Are the 
two RX channels being loaded simultaneously? Are you using timed commands to 
start the RX and TX streams?
Nick

On Tue, Mar 6, 2018 at 11:52 AM Prager, Samuel M (334E) via USRP-users 
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
Hello,

We are interested in using the E312 as a phase-sensitive radar sounder and have 
run into an interesting issue.

We are measuring (relative) cable length by estimating linear phase slope from 
a 10MHz chirp pulse and are using the following test setup (attached):

We have set the appropriate AD9361 registers to keep the VCO/PLL dividers on so 
that RXA (data) and RXB (calibration) are phase coherent. We perform pulse 
averaging on each channel and match filter with the cal channel pulse (shorter 
cable).

We have noticed that the phase measurements remain stable within <1 cm 99% 
confidence interval for successive trials with multiple re-tunings of the LO 
over long periods of time. However, we have found that if the FPGA bit file is 
unloaded (put in idle mode) and then reloaded (either through power-cycle or 
termination of UHD-based application), the measured phase slope jumps randomly.

We’re really scratching our heads over this behavior… multiple trials on a 
given ‘cycle’ remain stable around a mean value, but that value jumps around 
from cycle to cycle in a seemingly random way.

I have attached plots for two tests - the vertical black dotted lines are 
placed to show when the E312 FPGA image was cycled. Each data point is taken 
from a separate LO tuning (ie. tune to 400mhz, collect data, tune to 1ghz, 
wait, tune to 400mhz, collect data,…)

Any ideas about where could possibly be coming from? Is there somewhere in the 
E312 initialization that the relative path between RXA and RXB may be changed 
non-deterministically?

I really appreciate any help!

Thank you,

Sam

___
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Nick Foster via USRP-users]

Could you post your flowgraph or UHD program, or the relevant excerpts? Are
the two RX channels being loaded simultaneously? Are you using timed
commands to start the RX and TX streams?

Nick

On Tue, Mar 6, 2018 at 11:52 AM Prager, Samuel M (334E) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> We are interested in using the E312 as a phase-sensitive radar sounder and
> have run into an interesting issue.
>
>
>
> We are measuring (relative) cable length by estimating linear phase slope
> from a 10MHz chirp pulse and are using the following test setup (attached):
>
>
>
> We have set the appropriate AD9361 registers to keep the VCO/PLL dividers
> on so that RXA (data) and RXB (calibration) are phase coherent. We perform
> pulse averaging on each channel and match filter with the cal channel pulse
> (shorter cable).
>
>
>
> We have noticed that the phase measurements remain stable within <*1 cm* 99%
> confidence interval for successive trials with multiple re-tunings of the
> LO over long periods of time. However, we have found that if the FPGA bit
> file is unloaded (put in idle mode) and then reloaded (either through
> power-cycle or termination of UHD-based application), the measured phase
> slope jumps randomly.
>
>
>
> We’re really scratching our heads over this behavior… multiple trials on a
> given ‘cycle’ remain stable around a mean value, but that value jumps
> around from cycle to cycle in a seemingly random way.
>
>
>
> I have attached plots for two tests - the vertical black dotted lines are
> placed to show when the E312 FPGA image was cycled. Each data point is
> taken from a separate LO tuning (ie. tune to 400mhz, collect data, tune to
> 1ghz, wait, tune to 400mhz, collect data,…)
>
>
>
> Any ideas about where could possibly be coming from? Is there somewhere in
> the E312 initialization that the relative path between RXA and RXB may be
> changed non-deterministically?
>
>
>
> I really appreciate any help!
>
>
>
> Thank you,
>
>
>
> Sam
>
>
> ___
> 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