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