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 <spra...@usc.edu
<mailto:spra...@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=
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
