PS
Prager, Samuel M (334E)
Tue, Mar 6, 2018 7:51 PM
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
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
NF
Nick Foster
Tue, Mar 6, 2018 7:57 PM
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
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
>
PS
Prager, Samuel M (334E)
Tue, Mar 6, 2018 8:39 PM
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:bistromath@gmail.com]
Sent: Tuesday, March 06, 2018 11:57 AM
To: Prager, Samuel M (334E) samuel.m.prager@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.commailto: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.commailto:USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
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:bistromath@gmail.com]
Sent: Tuesday, March 06, 2018 11:57 AM
To: Prager, Samuel M (334E) <samuel.m.prager@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
SP
Samuel Prager
Fri, Mar 9, 2018 5:11 AM
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 12AD100000000000.
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:bistromath@gmail.com]
Sent: Tuesday, March 06, 2018 11:57 AM
To: Prager, Samuel M (334E) samuel.m.prager@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. 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
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 12AD100000000000.
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:bistromath@gmail.com]
> Sent: Tuesday, March 06, 2018 11:57 AM
> To: Prager, Samuel M (334E) <samuel.m.prager@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. 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
MD
Marcus D. Leech
Fri, Mar 9, 2018 5:29 AM
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
12AD100000000000.
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.
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
> 12AD100000000000.
> 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.
NF
Nick Foster
Fri, Mar 9, 2018 5:18 PM
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
12AD100000000000. 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
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
> 12AD100000000000. 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
>
SP
Samuel Prager
Fri, Mar 9, 2018 6:13 PM
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 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 12AD100000000000.
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
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 12AD100000000000.
> > > > 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&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=
NF
Nick Foster
Fri, Mar 9, 2018 6:22 PM
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 sprager@usc.edu 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
12AD100000000000. 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
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=
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 <sprager@usc.edu> 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
>> 12AD100000000000. 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=>
>>
> _______________________________________________
> 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&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=
>
>
SP
Samuel Prager
Fri, Mar 9, 2018 6:39 PM
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 bistromath@gmail.com, 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
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 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 12AD100000000000.
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
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 <bistromath@gmail.com>, 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 <sprager@usc.edu> 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 12AD100000000000.
> > > > > > > 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&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=
MD
Marcus D. Leech
Fri, Mar 9, 2018 7:20 PM
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 <sprager@usc.edu
mailto:sprager@usc.edu> 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 <mailto: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 <mailto: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 12AD100000000000.
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 <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=
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 <sprager@usc.edu
> <mailto:sprager@usc.edu>> 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 <mailto: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 <mailto: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 12AD100000000000.
>>> 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 <mailto:USRP-users@lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=
>
